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

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 15 Dec 2009 20:28:57 +0100 (CET)

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 <[email-masked]>
     * Cullen Jennings <[email-masked]>

Real-time Applications and Infrastructure Area Advisor:

     * Cullen Jennings <[email-masked]>

Mailing Lists:

General Discussion: [email-masked] [not yet in use]
To Subscribe: [email-masked] [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

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 15 Dec 2009 14:56:51 -0500

+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 

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: [email-masked] [mailto:[email-masked]] 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,
>  
>  _______________________________________________
>  dispatch mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Dec 2009 09:33:19 -0500

> 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