From bernie@ietf.hoeneisen.ch Sat Oct 10 07:03:34 2009 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED00628C102 for ; Sat, 10 Oct 2009 07:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEzdOCFW+KBE for ; Sat, 10 Oct 2009 07:03:33 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 56D3528C10B for ; Sat, 10 Oct 2009 07:03:33 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1MwcZS-0004hR-V2; Sat, 10 Oct 2009 16:05:19 +0200 Date: Sat, 10 Oct 2009 16:05:18 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: sob@harvard.edu In-Reply-To: <2A348BF3-388B-4248-B8A6-B208C8A3D75B@insensate.co.uk> Message-ID: References: <2A348BF3-388B-4248-B8A6-B208C8A3D75B@insensate.co.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: IETF ENUM WG Subject: Re: [Enum] 3761bis pre-LC comments X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 14:03:35 -0000 Hi Scott How is life? I just trying to track the issues with RFC 3761bis, as I understand RFC 3761bis is potentially holding up Enumservices-guide/-transition in the process due to tight interdependencies. What is the status of the points raised concerning sections 2.2 & 2.4 (see below)? Has this been addressed already? Do you intend to publish a revision within the next days, so that we can move on in the process? Thanks in advance for looking at this. Have a nice weekend! cheers, Bernie On Tue, 26 May 2009, Lawrence Conroy wrote: > Hi Esteemed co-chair and co-author of 3761, folks, > Re. "large objections to 3761bis ..." > > I already mentioned this, but there has been no comment on (or off) list, so > I repeat it. > It IS important, so I'd appreciate some response. I think we NEED to change > section 2. > The current version is incorrect for anything but terminal rules. > > For the rationale, see my original post on 2nd May: > > > Since that point, I have polished the proposed text, so here's what I think > is a sensible > and necessary replacement -- the changes are to the current section 2.2 and > 2.4 intro. > The 2.4 sub-sections have just been re-numbered and I've also zapped a couple > of typos. > > I suggest that this could be rolled into the next version along with any > other changes > reflecting LC or IESG comments (there is always another version in that > phase, I know it :). > > Comments please? > > all the best, > Lawrence > > --------------------------------------------------------------------------- > 2.1. Application Unique String > The Application Unique String (AUS) is a fully qualified E.164 number > minus any non-digit characters except for the '+' character which > appears at the beginning of the number. The '+' is kept to provide a > well understood anchor for the AUS in order to distinguish it from > other telephone numbers that are not part of the E.164 namespace. > > For example, the E.164 number could start out as "+44-116-496-0348". > To ensure that no syntactic sugar is allowed into the AUS, all non- > digits except for '+' are removed, yielding "+441164960348". > > 2.2. First Well Known Rule > The First Well Known Rule converts an Application Unique String (AUS) > into an initial key into the the Application's Rules Database. For > ENUM, the rules database is the DNS, so this key is a domain name. > > In order to convert the AUS to a unique key in this database the > string is converted into a domain name according to this algorithm: > > 1. Remove all characters with the exception of the digits. For > example, given the E.164 number "+44-20-7946-0148", this step > would simply remove the leading '+', producing "442079460148". > 2. Reverse the order of the digits. Example: "841064970244" > 3. Put dots ('.') between each digit. Example: > "4.4.2.0.7.9.4.6.0.1.4.8" > 4. Append the string ".e164.arpa." to the end. Example: > 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. > > The E.164 namespace and this Application's database are organized in > such a way that it is possible to go directly from the name to the > smallest granularity of the namespace directly from the name itself, > so no further processing is required to generate the initial key. > > This domain name is used to request NAPTR records. Each of these > records may contain the end result or, if its flags field is empty, > produces a new key in the form of a domain name that is used to > request further NAPTR records from the DNS. > > 2.3. Expected Output > The output of the last DDDS loop is a Uniform Resource Identifier in > its absolute form according to the 'absoluteURI' production in the > Collected ABNF found in RFC 3986[RFC3986]. > > 2.4. Valid Databases > At present only one DDDS Database is specified for this Application. > "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS > Database" [RFC3403] specifies a DDDS Database that uses the NAPTR DNS > resource record to contain the rewrite rules. The Keys for this > database are encoded as domain names. > > The character set used to encode the substitution expression is > UTF-8. The allowed input characters are all those characters that > are allowed anywhere in an E.164 number. The characters allowed to > be in a Key are those that are currently defined for DNS domain > names. > > 2.4.1. Optional Name Server Additional Section Processing > Some nameserver implementations attempt to be intelligent about items > that are inserted into the additional information section of a given > DNS response. For example, BIND will attempt to determine if it is > authoritative for a domain whenever it encodes one into a packet. If > it is, then it will insert any A records it finds for that domain > into the additional information section of the answer until the > packet reaches the maximum length allowed. It is therefore > potentially useful for a client to check for this additional > information. > > It is also easy to contemplate an ENUM enhanced nameserver that > understands the actual contents of the NAPTR records it is serving > and inserts more appropriate information into the additional > information section of the response. Thus, DNS servers MAY interpret > Flag values and use that information to include appropriate resource > records in the Additional Information portion of the DNS packet. > Clients are encouraged to check for additional information but are > not required to do so. See the Additional Information Processing > section of RFC 3403 [RFC3403], Section 4.2 for more information on > NAPTR records and the Additional Information section of a DNS > response packet. > > 2.4.2. Flags > This Database contains a field that contains flags that signal when > the DDDS algorithm has finished. At this time only one flag, "U", is > defined. This means that this Rule is the last one and that the > output of the Rule is a URI [RFC3986]. See RFC 3404 [RFC3404]. > > If a client encounters a record with an unknown flag, it MUST ignore > it and move to the next Rule. This test takes precedence over any > ordering since flags can control the interpretation placed on fields. > > A novel flag might change the interpretation of the regexp and/or > replacement fields such that it is impossible to determine if a > record matched a given target. > > If this flag is not present then this rule is non-terminal. If a > Rule is non-terminal then clients MUST use the Key produced by this > Rewrite Rule as the new Key in the DDDS loop (i.e., causing the > client to query for new NAPTR records at the domain name that is the > result of this Rule). > > 2.4.3. Services Parameters > Service Parameters for this Application take the following form and > are found in the Service field of the NAPTR record that holds a > terminal rule. Where the NAPTR holds a non-terminal Rule, the > Services field SHOULD be empty, and clients SHOULD ignore its > content. > > service-field = "E2U" 1*(servicespec) > servicespec = "+" enumservice > enumservice = type 0*(subtypespec) > subtypespec = ":" subtype > type = 1*32(ALPHA / DIGIT / "-") > subtype = 1*32(ALPHA / DIGIT / "-") > > In other words, a non-optional "E2U" (used to denote ENUM only > Rewrite Rules in order to mitigate record collisions) followed by one > or more Enumservices which indicate the class of functionality a > given end point offers. Each Enumservice is indicated by an initial > '+' character. > > 2.4.3.1. ENUM Services > Enumservices may be specified and registered via the process defined > in "Guide and Template for IANA Registrations of Enumservices" > [SV_GUIDE]. This registration process is not open to any Enumservice > that has '-' as the second character in its type string. > > In particular, this registration process is not open to Enumservice > types starting with the facet "X-". This "X-" facet is reserved for > experimental or trial use, and any such Enumservices cannot be > registered using the normal process. > > Finally, any Enumservice type that starts with the facet "P-" is > intended for use exclusively on private networks. As such, NAPTRs > containing Enumservice types starting "P-" should not be seen on the > global Internet. Even if an ENUM client recognizes and can engage in > the Enumservice, it may be incapable of resolving the URI generated > by the containing NAPTR. These Enumservices WILL NOT be registered. > > Such Enumservices MUST NOT be provisioned in any system that provides > answers to DNS queries for NAPTR resource record sets from entities > outside the private network context in which these Enumservices are > intended for use. > > Unless an ENUM client is sure that it is connected to the private > network for which these NAPTRs are provisioned and intended, it MUST > discard any NAPTR with an Enumservice type that starts with the "P-" > facet. > > 2.4.3.2. Compound NAPTRs and Implicit ORDER/REFERENCE Values > It is possible to have more than one Enumservice associated with a > single NAPTR. These Enumservices share the same Regexp field and so > generate the same URI. Such a "compound" NAPTR could well be used to > indicate a mobile phone that supports both "voice:tel" and "sms:tel" > Enumservices. The Services field in that case would be > "E2U+voice:tel+sms:tel". > > A compound NAPTR can be treated as a set of NAPTRs that each hold a > single Enumservice. These reconstructed NAPTRs share the same ORDER > and PREFERENCE/PRIORITY field values but should be treated as if each > had a logically different priority. ENUM clients SHOULD process the > Enumservices within a compound NAPTR in a left-to-right sequence. > ENUM provisioning systems SHOULD assume that such a processing order > will be used and provision the Enumservices within a compound NAPTR > accordingly. > > --------------------------------------------------------------------------- > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From richard@shockey.us Mon Oct 12 11:39:58 2009 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B33FF28C2AC for ; Mon, 12 Oct 2009 11:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2h7y0fQaoGA for ; Mon, 12 Oct 2009 11:39:57 -0700 (PDT) Received: from outbound-mail-140.bluehost.com (outbound-mail-140.bluehost.com [67.222.39.30]) by core3.amsl.com (Postfix) with SMTP id C664528C29E for ; Mon, 12 Oct 2009 11:39:57 -0700 (PDT) Received: (qmail 5913 invoked by uid 0); 12 Oct 2009 18:39:58 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy4.bluehost.com with SMTP; 12 Oct 2009 18:39:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=iW/kgBHUjq5qmA/pxrWALvRFBBNWN+r3aejuYxApYgy5it0dMjsNeqXVcqVf4hpeg+ZB9hVYRPSU2YeRyFax1KKsXgCqVcP3kBBUcT7AxEKVGWbgeObVNJsV3RuiKlAl; Received: from pool-96-255-226-99.washdc.fios.verizon.net ([96.255.226.99] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MxPoL-0005Nm-W5 for enum@ietf.org; Mon, 12 Oct 2009 12:39:58 -0600 From: "Richard Shockey" To: Date: Mon, 12 Oct 2009 14:39:50 -0400 Message-ID: <024501ca4b6b$6208d3d0$261a7b70$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpLZ+ubeVFnkQOMQZiTIYOzduKp3AAA14nw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.255.226.99 authed with richard+shockey.us} Subject: [Enum] FW: I-D Action:draft-hoeneisen-e164-to-metadata-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 18:39:58 -0000 Bernie ..what do you want to do with this? -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 12, 2009 2:15 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-hoeneisen-e164-to-metadata-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : E.164 to Metadata (E2M) Dynamic Delegation Discovery System (DDDS) Application Author(s) : B. Hoeneisen Filename : draft-hoeneisen-e164-to-metadata-00.txt Pages : 13 Date : 2009-10-12 This document proposes a new Dynamic Delegation Discovery System (DDDS) Application to map E.164 numbers to metadata. It discusses the use of the Domain Name System (DNS) for resolving E.164 numbers into metadata to provide information about E.164 numbers in cases where E.164 Number to URI Mapping (ENUM) can not be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-e164-to-metadata-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From richard@shockey.us Mon Oct 12 11:56:00 2009 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B0C28C261 for ; Mon, 12 Oct 2009 11:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZnFMCRrRIn9 for ; Mon, 12 Oct 2009 11:55:59 -0700 (PDT) Received: from outbound-mail-306.bluehost.com (outbound-mail-306.bluehost.com [67.222.53.252]) by core3.amsl.com (Postfix) with SMTP id BC5BF28C0F2 for ; Mon, 12 Oct 2009 11:55:59 -0700 (PDT) Received: (qmail 9039 invoked by uid 0); 12 Oct 2009 18:56:00 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 12 Oct 2009 18:56:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=ktCsa+nBuK2Bdcw72uplONfrFWKjczg89VZsu/2rvDc2AfqauH10suqMH8d7Xj19ThoapYVnKIq7HVaSJrLGP3pm+VhL6RXUWa0w+AqIthrNkh/4/ubVvZLEEuo394I/; Received: from pool-96-255-226-99.washdc.fios.verizon.net ([96.255.226.99] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MxQ3s-00053Z-5F for enum@ietf.org; Mon, 12 Oct 2009 12:56:00 -0600 From: "Richard Shockey" To: References: <024501ca4b6b$6208d3d0$261a7b70$@us> In-Reply-To: <024501ca4b6b$6208d3d0$261a7b70$@us> Date: Mon, 12 Oct 2009 14:55:52 -0400 Message-ID: <025101ca4b6d$9f7e8d70$de7ba850$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpLZ+ubeVFnkQOMQZiTIYOzduKp3AAA14nwAABuD7A= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.255.226.99 authed with richard+shockey.us} Subject: Re: [Enum] FW: I-D Action:draft-hoeneisen-e164-to-metadata-00.txt First Comment X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 18:56:00 -0000 Co-Chair hat off. For what it's worth I'm all for it. It would certainly solve a lot of problems I've had with the solution for CNAM. It would be trivial and extremely easy to implement for any number of PSTN parameters that are not functionally considered "routing data" that normally would be excluded from tel: uri's. > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Richard Shockey > Sent: Monday, October 12, 2009 2:40 PM > To: enum@ietf.org > Subject: [Enum] FW: I-D Action:draft-hoeneisen-e164-to-metadata-00.txt > > Bernie ..what do you want to do with this? > > > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, October 12, 2009 2:15 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-hoeneisen-e164-to-metadata-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : E.164 to Metadata (E2M) Dynamic Delegation > Discovery System (DDDS) Application > Author(s) : B. Hoeneisen > Filename : draft-hoeneisen-e164-to-metadata-00.txt > Pages : 13 > Date : 2009-10-12 > > This document proposes a new Dynamic Delegation Discovery System > (DDDS) Application to map E.164 numbers to metadata. > > It discusses the use of the Domain Name System (DNS) for resolving > E.164 numbers into metadata to provide information about E.164 numbers > in > cases where E.164 Number to URI Mapping (ENUM) can not be used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hoeneisen-e164-to-metadata- > 00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From bernie@ietf.hoeneisen.ch Mon Oct 12 11:57:20 2009 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D9B828C252 for ; Mon, 12 Oct 2009 11:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2q0JybFqb3M for ; Mon, 12 Oct 2009 11:57:19 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 2AF4728C0F2 for ; Mon, 12 Oct 2009 11:57:19 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1MxQ57-0006Kk-Pr; Mon, 12 Oct 2009 20:57:17 +0200 Date: Mon, 12 Oct 2009 20:57:17 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Richard Shockey In-Reply-To: <024501ca4b6b$6208d3d0$261a7b70$@us> Message-ID: References: <024501ca4b6b$6208d3d0$261a7b70$@us> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: IETF ENUM list Subject: Re: [Enum] FW: I-D Action:draft-hoeneisen-e164-to-metadata-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 18:57:20 -0000 Hi Rich As outlined in the Introduction section, the proposal in draft-hoeneisen-e164-to-metadata-00.txt intends provide a means to deblock some "problematic" Enumservices (e.g. cnam, unused/void) as well as to enable to creation of services, which would otherwise not be possible (within the ENUM framework), but are used in todays ENUM deployments. > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hoeneisen-e164-to-metadata-00.txt In short: "[...] resolving E.164 numbers into metadata to provide information about E.164 numbers in cases where [...] ENUM can not be used." cheers, Bernie PS: The ENUM WG list is used for discussion on this proposal, until it has a proper home. On Mon, 12 Oct 2009, Richard Shockey wrote: > Bernie ..what do you want to do with this? > > > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, October 12, 2009 2:15 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-hoeneisen-e164-to-metadata-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : E.164 to Metadata (E2M) Dynamic Delegation > Discovery System (DDDS) Application > Author(s) : B. Hoeneisen > Filename : draft-hoeneisen-e164-to-metadata-00.txt > Pages : 13 > Date : 2009-10-12 > > This document proposes a new Dynamic Delegation Discovery System > (DDDS) Application to map E.164 numbers to metadata. > > It discusses the use of the Domain Name System (DNS) for resolving > E.164 numbers into metadata to provide information about E.164 numbers in > cases where E.164 Number to URI Mapping (ENUM) can not be used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hoeneisen-e164-to-metadata-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum > From rfc-editor@rfc-editor.org Mon Oct 12 16:03:05 2009 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E22633A68D3; Mon, 12 Oct 2009 16:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.299 X-Spam-Level: X-Spam-Status: No, score=-17.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGGZ5mEZH230; Mon, 12 Oct 2009 16:03:05 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 2A82E3A6886; Mon, 12 Oct 2009 16:03:05 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 6F663343C48; Mon, 12 Oct 2009 16:01:13 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091012230113.6F663343C48@bosco.isi.edu> Date: Mon, 12 Oct 2009 16:01:13 -0700 (PDT) Cc: enum@ietf.org, rfc-editor@rfc-editor.org Subject: [Enum] RFC 5333 on IANA Registration of Enumservices for Internet Calendaring X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 23:03:06 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5333 Title: IANA Registration of Enumservices for Internet Calendaring Author: R. Mahy, B. Hoeneisen Status: Standards Track Date: October 2009 Mailbox: rohan@ekabal.com, bernie@ietf.hoeneisen.ch Pages: 8 Characters: 13945 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-calendar-service-04.txt URL: http://www.rfc-editor.org/rfc/rfc5333.txt This document registers Enumservices for Internet calendaring. Specifically, this document focuses on Enumservices for scheduling with iMIP (iCalendar Message-Based Interoperability Protocol) and for accessing Internet calendaring information with CalDAV (Calendaring Extensions to WebDAV). [STANDARDS TRACK] This document is a product of the Telephone Number Mapping Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From Ray.Bellis@nominet.org.uk Tue Oct 13 00:11:35 2009 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A287D3A68E3 for ; Tue, 13 Oct 2009 00:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OobQEg1srWzV for ; Tue, 13 Oct 2009 00:11:34 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id C91BE3A679F for ; Tue, 13 Oct 2009 00:11:33 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=TtezPtVYVM1yK8F3bynY2Ex6PWbttEU6PJlOfm5Tba0UKYwQ2NaH1N7p XY14ALXPmdMHrCWEGMY6D+o2ZiwoLI0chUqu9e+ljYE/1aVobBVdfccHL SdrWSgT7qEyNniP; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1255417895; x=1286953895; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Enum ]=20FW:=20I-D=20Action:draft-hoeneisen-e164-to-metadata-0 0.txt=09First=0D=0A=20Comment|Date:=20Tue,=2013=20Oct=202 009=2008:11:33=20+0100|Message-ID:=20 |To:=20"Richard=20Shockey"=20|Cc:=20e num@ietf.org|MIME-Version:=201.0|In-Reply-To:=20<025101ca 4b6d$9f7e8d70$de7ba850$@us>|References:=20<024501ca4b6b$6 208d3d0$261a7b70$@us>=20<025101ca4b6d$9f7e8d70$de7ba850$@ us>; bh=4l58ogfgagD+HEYxqmfrJ7M6BFqpwpyNJ15+dk73Wow=; b=61p3vzCFzKUbBnsePNBpZ8l+j2KqLlm8RbpEYUptj6ZSDK7nXd380Jmm w4xY7yS9Shf8SasLr1SzOIWvtzvzzz1FNooFmIRskZrRJZZ3UOdxQPt2d kmDAWVNfiykm/fG; X-IronPort-AV: E=Sophos;i="4.44,550,1249254000"; d="scan'208";a="18518657" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 13 Oct 2009 08:11:34 +0100 In-Reply-To: <025101ca4b6d$9f7e8d70$de7ba850$@us> References: <024501ca4b6b$6208d3d0$261a7b70$@us> <025101ca4b6d$9f7e8d70$de7ba850$@us> To: "Richard Shockey" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 13 Oct 2009 08:11:33 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 13/10/2009 08:11:34 AM, Serialize complete at 13/10/2009 08:11:34 AM Content-Type: multipart/alternative; boundary="=_alternative 002782768025764E_=" Cc: enum@ietf.org Subject: Re: [Enum] FW: I-D Action:draft-hoeneisen-e164-to-metadata-00.txt First Comment X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 07:11:35 -0000 This is a multipart message in MIME format. --=_alternative 002782768025764E_= Content-Type: text/plain; charset="US-ASCII" > Co-Chair hat off. > > For what it's worth I'm all for it. It would certainly solve a lot of > problems I've had with the solution for CNAM. It would be trivial and > extremely easy to implement for any number of PSTN parameters that are not > functionally considered "routing data" that normally would be excluded from > tel: uri's. I could certainly use it - it would be perfect for my Send-N draft. Ray --=_alternative 002782768025764E_= Content-Type: text/html; charset="US-ASCII"
> Co-Chair hat off.
>
> For what it's worth I'm all for it. It would certainly solve a lot of
> problems I've had with the solution for CNAM. It would be trivial and
> extremely easy to implement for any number of PSTN parameters that are not
> functionally considered "routing data" that normally would be excluded from
> tel: uri's.

I could certainly use it - it would be perfect for my Send-N draft.

Ray
--=_alternative 002782768025764E_=-- From bernie@ietf.hoeneisen.ch Tue Oct 13 06:55:55 2009 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F089B28C1ED for ; Tue, 13 Oct 2009 06:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[AWL=-2.298, BAYES_00=-2.599, FB_LETTERS_21B=3.995, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85TKiQ5UNm7R for ; Tue, 13 Oct 2009 06:55:54 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 74B6A28C1E4 for ; Tue, 13 Oct 2009 06:55:54 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1Mxhqx-0002IG-FE; Tue, 13 Oct 2009 15:55:51 +0200 Date: Tue, 13 Oct 2009 15:55:51 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Alfred H?nes In-Reply-To: <200910131203.OAA22281@TR-Sys.de> Message-ID: References: <200910131203.OAA22281@TR-Sys.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: IETF ENUM list Subject: Re: [Enum] draft-hoeneisen-e164-to-metadata-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 13:55:56 -0000 Hi Alfred Thanks a lot for your extensive feedback. As always, good catches! It'll be incorporated to revision -01. cheers, Bernie On Tue, 13 Oct 2009, Alfred H?nes wrote: > Bernie, > I have quickly skimmed over your new E2M draft, > draft-hoeneisen-e164-to-metadata-00, and have a couple of > comments, mostly editorials / clarifications. > > First of all, this seems a reasonable proposal in order to keep > the ENUM space 'clean' from the perspective of user expectations > and client software trying to accommodate that. > Also, the basic ideas seem to already be worked out thoroughly > and specified in sufficient detail. > > Here is a linear walk-through of the text with the details > I'd like to be addressed: > > > (1) Section 1, 2nd para (+ ff.) -- clarification, and a word omission > > The draft says: > v > | Thus, ENUM can be used look up the services associated with an E.164 > number. However, it is controversial whether or not the result of an > | ENUM lookup should always result in a communications session using > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > the URI found in the corresponding Naming Authority Pointer (NAPTR) > [RFC3403] DNS Resource Record (RR). > > The expectation "should always result in a communications session" > seems to be too strong; it even cannot be fulfilled by 'classical' > ENUM. I suggest that either here, or in Section 1.2, or in both > places, the related text is modified to indicate the *intent*, > not the requirement for *success*. > > Also, please add the missing "to" in the 1st line. > > Altogether, I propose to modify the above paragraph to say: > > vvvv > | Thus, ENUM can be used to look up the services associated with an > E.164 number. However, it is controversial whether or not the result > | of an ENUM lookup should always be suitable for establishing a > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > communications session using the URI found in the corresponding > Naming Authority Pointer (NAPTR) [RFC3403] DNS Resource Record (RR). > > > (2) Section 1.2 > > (2a) 2nd para -- typo > v > | Another issue is that the result of a ENUM (E2U) lookup always needs > to be an URI, which makes otherwise simple mappings rather complex. > --- vv > | Another issue is that the result of an ENUM (E2U) lookup always needs > to be an URI, which makes otherwise simple mappings rather complex. > > (2b) 3rd para -- clarification, and a missing article > > As in (1) above, I suggest a clarification of the expectations for > ENUM, and the addition of a missing article and typographical emphasis > for the 'data' URI scheme, as follows: > > The authors of such Enumservice proposals tried to circumvent the > | issues by introducing data URI scheme or inventing completely new URI > schemes, with limited success however. The main objection that an > | ENUM lookup should always result in a communications session > remained. > --- > The authors of such Enumservice proposals tried to circumvent the > | issues by introducing the 'data' URI scheme or inventing completely > ^^^^^ ^ > new URI schemes, with limited success however. The main objection > | remained that an ENUM lookup should always result in a URI that can > ^^^^^^^^^ ^^^^^^^^^^^^^^ > | be used to establish a communications session. > ^^^^^^^^^^^^^^^^^^^^^ ^ > > Here, I also have modified the word placement (which resembled German > style :-) ) for better readability. > > > (3) Section 1.3 > > (3a) 1st para -- grammar > > I suggest to resolve singular/plural issues and remove a spurious "for": > > This document proposes a new Dynamic Delegation Discovery System > | (DDDS) [RFC3401] application E2M, which can be used with DNS NAPTR RR > for resolving E.164 numbers into metadata. The resulting metadata > | can be used for (for example) to provide hints about properties of > certain ENUM domains or to provide information that can be used as > | attribute of an E.164 number. > --- > This document proposes a new Dynamic Delegation Discovery System > (DDDS) [RFC3401] application E2M, which can be used with DNS NAPTR > | RRs for resolving E.164 numbers into metadata. The resulting > ^ v > | metadata can be used (for example) to provide hints about properties > of certain ENUM domains or to provide information that can be used as > | attributes of an E.164 number. > ^ > > (3b) 3rd para -- extraneous word > > The "and" in the last line should be deleted: > > As there are lots of similarities between E2M and ENUM (E2U), this > document generally only outlines the differences to ENUM (E2U) > instead of repeating all parts shared between the two. Therefore a > firm understanding of ENUM [I-D.ietf-enum-3761bis] and Enumservices > | [I-D.ietf-enum-enumservices-guide] and is required. > --- ^^^^^ > As there are lots of similarities between E2M and ENUM (E2U), this > document generally only outlines the differences to ENUM (E2U) > instead of repeating all parts shared between the two. Therefore a > firm understanding of ENUM [I-D.ietf-enum-3761bis] and Enumservices > | [I-D.ietf-enum-enumservices-guide] is required. > ^ > > (4) Section 1.4 -- word omission > > Please insert the missing indefinite article in the first line: > > | This is work in progress at early stage. [...] > --- vvvv > | This is work in progress at an early stage. [...] > > > (5) Section 3.1 -- I18N considerations > > | o An ASCII Text string > > This needs clarification and justification (with regard to RFC 2277). > > I interpret the draft in such way that these strings are intended > to be machine readable and suitable for consumption by automata, > not for direct display to users. In this case, the strings would > be regarded as a kind of protocol elements, thus waiving the > RFC 2277 requirements for I18N and UTF-8 support in text elements. > > If that perception is true, an explanation to this end should be > inserted directly below the quoted bullet headline (you may directly > rephrase the arguments given above). > > However, the indication in the 3rd para of Section 4.1.1 does not > properly match this idea. See the related discussion below. > > > (6) Section 3.2, last para -- inconsistency > > Since the main part of that section specifies the use of two different > flags, "t" and "u", plural should be used in the first sentence: > > | If this flag is not present then this rule is non-terminal. [...] > --- vvvvvvvvvvvvvvvvvvvvvvvvvv > | If none of the above flags is present then this rule is non-terminal. > [...] > > > (7) Section 3.3, 1st para -- typo > > The single quote character in the 1st line is unmatched; please fix: > > | Section '2.4.4. Services Parameters of [I-D.ietf-enum-3761bis] is > replaced as follows: > --- v > | Section '2.4.4. Services Parameters' of [I-D.ietf-enum-3761bis] is > replaced as follows: > > > (8) Section 4.1.1 -- language improvements > > I suggest to user "constrain" in favor of "limit" w.r.t. ABNF. > The word "limit" is perhaps too much correlated with thinking in > linear dimensions, number intervals, etc., and not appropriate for > a syntax rule set expressed in ABNF. > > (8a) 1st para > > Beyond the above, the wording in the first sentence should be > improved and "of" should be inserted after every instance of > "Section 3.2". > > Furthermore, in the last sentence a better distinction should be > made between ABNF rules and the possible instances of text allowed > (or "produced") by them; "a subset" of the ABNF is very different > from "a subset of the strings allowed by the ABNF", and the latter > is indeed meant here (I hope!). > I try to fix this below, but feel free to find other suitable words. > > In total, I suggest to change this paragraph as follows: > > | The ABNF [RFC5234] to limit the ASCII Text string the E2M service > resolves. The 'Substitution Expression Syntax' is specified in > | Section 3.2 [RFC3402]). Any parts of ABNF further specified in an > E2M service specification override those parts of ABNF specified in > | Section 3.2 [RFC3402]). However, the resulting ABNF MUST be a subset > | of the ABNF specified in Section 3.2 [RFC3402]). > --- vvvvvvvvv vvvvvvvvvv > | The ABNF [RFC5234] to constrain the ASCII Text string to which the > E2M service resolves. The 'Substitution Expression Syntax' is > | specified in Section 3.2 of [RFC3402]). Any parts of ABNF further > ^^^^ > specified in an E2M service specification override those parts of > | ABNF specified in Section 3.2 of [RFC3402]). However, the resulting > ^^^^ > | ABNF MUST produce a subset of the text strings produced by the ABNF > ^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > | specified in Section 3.2 of [RFC3402]). > ^^^^ > > (8b) 2nd para > > Following the reasoning in (8), I recommend to adjust: > > Typically only the 'repl' part of the ABNF needs to be further > specified. However, in rare cases (depending on the application) > | also a limitation of the 'delim-char' part may be justified (see also > 4th example below). > --- > Typically only the 'repl' part of the ABNF needs to be further > specified. However, in rare cases (depending on the application) > | also a constraint for the 'delim-char' part may be justified (see > ^^^^^^^^^^^^^^ > also 4th example below). > > > That's all for this moment! > > Kind regards, > Alfred H?nes. > > -- > > +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | > +------------------------+--------------------------------------------+ > > From root@core3.amsl.com Wed Oct 14 02:45:04 2009 Return-Path: X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 70D7A3A68FC; Wed, 14 Oct 2009 02:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091014094502.70D7A3A68FC@core3.amsl.com> Date: Wed, 14 Oct 2009 02:45:02 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] I-D Action:draft-ietf-enum-enumservices-transition-04.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 09:45:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : Update of legacy IANA Registrations of Enumservices Author(s) : B. Hoeneisen, A. Mayrhofer Filename : draft-ietf-enum-enumservices-transition-04.txt Pages : 68 Date : 2009-10-14 This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in [RFC3761]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-transition-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-enum-enumservices-transition-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-14024257.I-D@ietf.org> --NextPart-- From A.Hoenes@TR-Sys.de Tue Oct 13 05:04:24 2009 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFBCF28C0E7 for ; Tue, 13 Oct 2009 05:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.271 X-Spam-Level: **** X-Spam-Status: No, score=4.271 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FB_LETTERS_21B=3.995, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4T0Jf0tKe6UA for ; Tue, 13 Oct 2009 05:04:23 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 0339828C159 for ; Tue, 13 Oct 2009 05:04:21 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA223755417; Tue, 13 Oct 2009 14:03:37 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA22281; Tue, 13 Oct 2009 14:03:32 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910131203.OAA22281@TR-Sys.de> To: bernie@ietf.hoeneisen.ch Date: Tue, 13 Oct 2009 14:03:32 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 14 Oct 2009 06:47:41 -0700 Cc: enum@ietf.org Subject: [Enum] draft-hoeneisen-e164-to-metadata-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 12:04:24 -0000 Bernie, I have quickly skimmed over your new E2M draft, draft-hoeneisen-e164-to-metadata-00, and have a couple of comments, mostly editorials / clarifications. First of all, this seems a reasonable proposal in order to keep the ENUM space 'clean' from the perspective of user expectations and client software trying to accommodate that. Also, the basic ideas seem to already be worked out thoroughly and specified in sufficient detail. Here is a linear walk-through of the text with the details I'd like to be addressed: (1) Section 1, 2nd para (+ ff.) -- clarification, and a word omission The draft says: v | Thus, ENUM can be used look up the services associated with an E.164 number. However, it is controversial whether or not the result of an | ENUM lookup should always result in a communications session using !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! the URI found in the corresponding Naming Authority Pointer (NAPTR) [RFC3403] DNS Resource Record (RR). The expectation "should always result in a communications session" seems to be too strong; it even cannot be fulfilled by 'classical' ENUM. I suggest that either here, or in Section 1.2, or in both places, the related text is modified to indicate the *intent*, not the requirement for *success*. Also, please add the missing "to" in the 1st line. Altogether, I propose to modify the above paragraph to say: vvvv | Thus, ENUM can be used to look up the services associated with an E.164 number. However, it is controversial whether or not the result | of an ENUM lookup should always be suitable for establishing a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ communications session using the URI found in the corresponding Naming Authority Pointer (NAPTR) [RFC3403] DNS Resource Record (RR). (2) Section 1.2 (2a) 2nd para -- typo v | Another issue is that the result of a ENUM (E2U) lookup always needs to be an URI, which makes otherwise simple mappings rather complex. --- vv | Another issue is that the result of an ENUM (E2U) lookup always needs to be an URI, which makes otherwise simple mappings rather complex. (2b) 3rd para -- clarification, and a missing article As in (1) above, I suggest a clarification of the expectations for ENUM, and the addition of a missing article and typographical emphasis for the 'data' URI scheme, as follows: The authors of such Enumservice proposals tried to circumvent the | issues by introducing data URI scheme or inventing completely new URI schemes, with limited success however. The main objection that an | ENUM lookup should always result in a communications session remained. --- The authors of such Enumservice proposals tried to circumvent the | issues by introducing the 'data' URI scheme or inventing completely ^^^^^ ^ new URI schemes, with limited success however. The main objection | remained that an ENUM lookup should always result in a URI that can ^^^^^^^^^ ^^^^^^^^^^^^^^ | be used to establish a communications session. ^^^^^^^^^^^^^^^^^^^^^ ^ Here, I also have modified the word placement (which resembled German style :-) ) for better readability. (3) Section 1.3 (3a) 1st para -- grammar I suggest to resolve singular/plural issues and remove a spurious "for": This document proposes a new Dynamic Delegation Discovery System | (DDDS) [RFC3401] application E2M, which can be used with DNS NAPTR RR for resolving E.164 numbers into metadata. The resulting metadata | can be used for (for example) to provide hints about properties of certain ENUM domains or to provide information that can be used as | attribute of an E.164 number. --- This document proposes a new Dynamic Delegation Discovery System (DDDS) [RFC3401] application E2M, which can be used with DNS NAPTR | RRs for resolving E.164 numbers into metadata. The resulting ^ v | metadata can be used (for example) to provide hints about properties of certain ENUM domains or to provide information that can be used as | attributes of an E.164 number. ^ (3b) 3rd para -- extraneous word The "and" in the last line should be deleted: As there are lots of similarities between E2M and ENUM (E2U), this document generally only outlines the differences to ENUM (E2U) instead of repeating all parts shared between the two. Therefore a firm understanding of ENUM [I-D.ietf-enum-3761bis] and Enumservices | [I-D.ietf-enum-enumservices-guide] and is required. --- ^^^^^ As there are lots of similarities between E2M and ENUM (E2U), this document generally only outlines the differences to ENUM (E2U) instead of repeating all parts shared between the two. Therefore a firm understanding of ENUM [I-D.ietf-enum-3761bis] and Enumservices | [I-D.ietf-enum-enumservices-guide] is required. ^ (4) Section 1.4 -- word omission Please insert the missing indefinite article in the first line: | This is work in progress at early stage. [...] --- vvvv | This is work in progress at an early stage. [...] (5) Section 3.1 -- I18N considerations | o An ASCII Text string This needs clarification and justification (with regard to RFC 2277). I interpret the draft in such way that these strings are intended to be machine readable and suitable for consumption by automata, not for direct display to users. In this case, the strings would be regarded as a kind of protocol elements, thus waiving the RFC 2277 requirements for I18N and UTF-8 support in text elements. If that perception is true, an explanation to this end should be inserted directly below the quoted bullet headline (you may directly rephrase the arguments given above). However, the indication in the 3rd para of Section 4.1.1 does not properly match this idea. See the related discussion below. (6) Section 3.2, last para -- inconsistency Since the main part of that section specifies the use of two different flags, "t" and "u", plural should be used in the first sentence: | If this flag is not present then this rule is non-terminal. [...] --- vvvvvvvvvvvvvvvvvvvvvvvvvv | If none of the above flags is present then this rule is non-terminal. [...] (7) Section 3.3, 1st para -- typo The single quote character in the 1st line is unmatched; please fix: | Section '2.4.4. Services Parameters of [I-D.ietf-enum-3761bis] is replaced as follows: --- v | Section '2.4.4. Services Parameters' of [I-D.ietf-enum-3761bis] is replaced as follows: (8) Section 4.1.1 -- language improvements I suggest to user "constrain" in favor of "limit" w.r.t. ABNF. The word "limit" is perhaps too much correlated with thinking in linear dimensions, number intervals, etc., and not appropriate for a syntax rule set expressed in ABNF. (8a) 1st para Beyond the above, the wording in the first sentence should be improved and "of" should be inserted after every instance of "Section 3.2". Furthermore, in the last sentence a better distinction should be made between ABNF rules and the possible instances of text allowed (or "produced") by them; "a subset" of the ABNF is very different from "a subset of the strings allowed by the ABNF", and the latter is indeed meant here (I hope!). I try to fix this below, but feel free to find other suitable words. In total, I suggest to change this paragraph as follows: | The ABNF [RFC5234] to limit the ASCII Text string the E2M service resolves. The 'Substitution Expression Syntax' is specified in | Section 3.2 [RFC3402]). Any parts of ABNF further specified in an E2M service specification override those parts of ABNF specified in | Section 3.2 [RFC3402]). However, the resulting ABNF MUST be a subset | of the ABNF specified in Section 3.2 [RFC3402]). --- vvvvvvvvv vvvvvvvvvv | The ABNF [RFC5234] to constrain the ASCII Text string to which the E2M service resolves. The 'Substitution Expression Syntax' is | specified in Section 3.2 of [RFC3402]). Any parts of ABNF further ^^^^ specified in an E2M service specification override those parts of | ABNF specified in Section 3.2 of [RFC3402]). However, the resulting ^^^^ | ABNF MUST produce a subset of the text strings produced by the ABNF ^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | specified in Section 3.2 of [RFC3402]). ^^^^ (8b) 2nd para Following the reasoning in (8), I recommend to adjust: Typically only the 'repl' part of the ABNF needs to be further specified. However, in rare cases (depending on the application) | also a limitation of the 'delim-char' part may be justified (see also 4th example below). --- Typically only the 'repl' part of the ABNF needs to be further specified. However, in rare cases (depending on the application) | also a constraint for the 'delim-char' part may be justified (see ^^^^^^^^^^^^^^ also 4th example below). That's all for this moment! Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From richard@shockey.us Mon Oct 26 15:24:42 2009 Return-Path: X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C1028C190 for ; Mon, 26 Oct 2009 15:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owxZ9wUJpNks for ; Mon, 26 Oct 2009 15:24:41 -0700 (PDT) Received: from outbound-mail-316.bluehost.com (outbound-mail-316.bluehost.com [67.222.54.9]) by core3.amsl.com (Postfix) with SMTP id 08F8D3A68C9 for ; Mon, 26 Oct 2009 15:24:41 -0700 (PDT) Received: (qmail 2870 invoked by uid 0); 26 Oct 2009 22:24:54 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 26 Oct 2009 22:24:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=KygzU0JJzi0J2seiGuQ4nRFbjmtoii1KW6BM9lhOW3E+bLwR+7JxWYLmYJsgkcldlBMbg8v9OgQfiOo5Ev4bbFiH8DSETFWVq8Yc0WtlVNCqf4zvPax6vZr+ACdpiyPs; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N2Xzi-0001Ft-9Z for enum@ietf.org; Mon, 26 Oct 2009 16:24:54 -0600 From: "Richard Shockey" To: Date: Mon, 26 Oct 2009 18:24:52 -0400 Message-ID: <06e601ca568b$23dd29a0$6b977ce0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpWf280Kd71k8ahR1mA52VAwlSZfQAC6pbA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Subject: [Enum] FW: I-D Action:draft-malas-enum-trunk-sip-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 22:24:42 -0000 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 26, 2009 5:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-malas-enum-trunk-sip-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Trunk Group Use in ENUM Author(s) : D. Malas, T. Creighton Filename : draft-malas-enum-trunk-sip-01.txt Pages : 9 Date : 2009-10-26 This document describes a method for incorporating trunk group parameters into an E.164 Number Mapping (ENUM) response for the Session Initiation Protocol (SIP) [RFC3261] service URI. It defines the use of trunk group contexts as defined in [RFC4904] as additional parameters in the E2U+SIP enumservice NAPTR record [RFC3403] URI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-malas-enum-trunk-sip-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.