[Enum] 3761bis pre-LC comments

[Lawrence Conroy <lconroy at insensate.co.uk>]

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.

---------------------------------------------------------------------------