Re: 3761bis pre-LC comments

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:
> <http://www.ietf.org/mail-archive/web/enum/current/msg06879.html>
>
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/enum