[Enum] FW: [dispatch] E2M: Proposed Charter (draft version only)

FYI my note to DISPATCH

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
Sent: Wednesday, December 16, 2009 9:33 AM
To: Richard Shockey
Cc: 'IETF DISPATCH list'
Subject: Re: [dispatch] E2M: Proposed Charter (draft version only)

Richard Shockey wrote:
> +1 in support of this charter
> 
> As the editor of the ENUM draft on CNAM frankly I was a bit appalled at
what
> I was forced to go through to try and make this work to the satisfaction
of
> some in the RAI directorate and the IESG.  The result was nothing if not a
> total kludge (see the draft) . It would have been much simpler to add the
> parameter to the SIP URI but there are those that have a layer 10
conviction
> that only routing information can be in the URI... but then I couldn't use
> the DATA URI since that was too much like TXT RR's etc. So you have to
> invent a total kludge PSTN PSTNDATA uri 

I'm not sure if I am one of "those that have a layer 10 conviction" or 
not. I did argue against adding a parameter to the sip URI, not because 
of a general objection to non-routing information in a URI, but rather 
an objection to spurious information in a URI type that *is* intended 
for routing.

I recommended the data URI, and never understood the arguments against it.

This proposal seems like a reasonable way forward, modulo my limited 
knowledge of DNS.

	Thanks,
	Paul

> http://tools.ietf.org/html/draft-ietf-enum-cnam-08
> 
> The point here is, BTW, that phone numbers are not going away. Not now not
> ever, some folks just need to get over that issue ASAP. 99.9999 % of all
SIP
> transactions in the field involve phone numbers and there needs to be
> simpler and more effective way of expressing and or looking up metadata
> associated with those identifiers.
> 
>>  -----Original Message-----
>>  From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
>>  Behalf Of Bernie Hoeneisen
>>  Sent: Tuesday, December 15, 2009 2:29 PM
>>  To: IETF DISPATCH list
>>  Subject: [dispatch] E2M: Proposed Charter (draft version only)
>>  
>>  Hi,
>>  
>>  As suggested by Mary (DISPATCH co-chair), I wrote up a proposal for an
>>  E2M
>>  charter (draft) for discussion on this mailing list.
>>  
>>  Have fun!
>>  
>>  cheers,
>>    Bernie
>>  
>>  ---
>>  
>>  E.164 to Metadata (E2M) (proposed charter / draft state)
>>  -----------------------
>>  
>>  Last Modified: 2009-12-15
>>  
>>  Additional information is available at tools.ietf.org/wg/e2m
>>  [not yet in use]
>>  
>>  
>>  Chair(s):
>>  
>>       * TBA
>>  
>>  Real-time Applications and Infrastructure Area Director(s):
>>  
>>       * Robert Sparks <rjsparks@nostrum.com>
>>       * Cullen Jennings <fluffy@cisco.com>
>>  
>>  Real-time Applications and Infrastructure Area Advisor:
>>  
>>       * Cullen Jennings <fluffy@cisco.com>
>>  
>>  
>>  Mailing Lists:
>>  
>>  General Discussion: e2m@ietf.org [not yet in use]
>>  To Subscribe: e2m-request@ietf.org [not yet in use]
>>  In Body: subscribe
>>  Archive: http://www.ietf.org/mail-archive/web/e2m/index.html
>>            [not yet in use]
>>  
>>  
>>  Description of Working Group:
>>  
>>  Abstract
>>  
>>      E.164 to Metadata (E2M) will 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.
>>  
>>  
>>  Background
>>  
>>      ENUM provides an identifier mapping mechanism to map E.164 numbers
>>      to Uniform Resource Identifiers (URIs) using the DNS.
>>  
>>      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 intended to establish a
>>      communications session using the URI found in the corresponding
>>      Naming Authority Pointer (NAPTR) DNS Resource Record (RR).
>>  
>>  
>>  Problem Statement
>>  
>>      Several proposals for Enumservice registrations do not fulfill the
>>      above mentioned interpretation, which suggests that an ENUM lookup
>>      should always be intended to result in a communications session.
>>      These proposals are therefore virtually locked in the process.
>>      Such proposals include (but are not limited to) Enumservices for
>>      'cnam' to provide information about the calling party name,
>>      'unused' to provide a hint that a number is not in use, and
>>      'send-n' to describe the structure of an ENUM tree.
>>  
>>      Another issue is that the result of an ENUM (E2U) lookup always
>>      needs to be an URI, which unnecessarily complicates simple
>>  mappings.
>>  
>>      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
>>  intended
>>      to establish a communications session.
>>  
>>  Proposal
>>  
>>      The E2M Working Group is chartered to develop a new Dynamic
>>      Delegation Discovery System (DDDS) application E2M, which can be
>>      used with DNS NAPTR RRs for resolving E.164 numbers into metadata.
>>      The resulting 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.
>>  
>>      E2M will provide the means for services related to E.164 numbers
>>      that do not fit into the concept of ENUM (E2U), and thus a
>>      way forward for such existing ENUM WG documents in the queue.
>>  
>>      Along with the E2M DDDS application a new IANA registry will be
>>      specified for registration of E2M services. The registration
>>  policy
>>      shall be Expert Review and Specification Required (see RFC 5226),
>>      similarly as specified for Enumservice registrations.
>>  
>>      The E2M specifications shall reuse a much as possible from the
>>  ENUM
>>      DDDS and its IANA registry specification.
>>  
>>      The E2M Working Group may take on further proposals for E2M
>>  service
>>      registrations (e.g. send-n) until the IANA registration for E2M
>>      services is approved by the IESG.
>>  
>>  
>>  Goals and Milestones:
>>  
>>      Aug 2010  Submit Internet Draft(s) for the E2M DDDS application
>>  and
>>                its IANA registry specification
>>  
>>      Dec 2010  Submit 'cnam' and 'unused' as E2M service registrations
>>                (Informational)
>>  
>>      XXX 2011  Close the E2M Working Group (or recharter)
>>  
>>  
>>  Internet-Drafts:
>>  
>>      http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-01
>>      http://tools.ietf.org/html/draft-ietf-enum-unused-04
>>      http://tools.ietf.org/html/draft-ietf-enum-cnam-08
>>      (http://tools.ietf.org/html/draft-bellis-enum-send-n-02)
>>  
>>  
>>  Request For Comments:
>>  
>>      None
>>  
>>  _______________________________________________
>>  dispatch mailing list
>>  dispatch@ietf.org
>>  https://www.ietf.org/mailman/listinfo/dispatch
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 