[e2md] Draft charter, comments inline <dw>

[Dean Willis <[e-mail]>]

E.164 to MetaData (E2MD) (proposed charter)
------------------------

Last Modified: 2010-03-05

Additional information is available at tools.ietf.org/wg/e2md
[not yet in use]


Chair(s):

     * TBA

Real-time Applications and Infrastructure Area Director(s):

     * Robert Sparks <[e-mail]>
     * Cullen Jennings <[e-mail]>

Real-time Applications and Infrastructure Area Advisor:

     * Cullen Jennings <[e-mail]>


Mailing Lists:

    General Discussion: [e-mail]
    Listinfo: https://www.ietf.org/mailman/listinfo/e2md
    To Subscribe: [e-mail]
    In Body: subscribe
    Archive: http://www.ietf.org/mail-archive/web/e2md/index.html



Description of Working Group:

Abstract

    E.164 to MetaData (E2MD) will use of the Domain Name System (DNS)
<dw> either "make" before "use" or delete "of" in the preceding</dw>

    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.

<dw> IS thsi true? I thought we were adding metadata mapping alongside  
the URI mapping for the e.164 number </dw>



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).

<dw> No, it's not. The result of an ENUM lookup is either nothing or a  
URI. Are you saying that encoding other cruft into the URI that makes  
the URI non-usable for contact purpose is controversial? That's not  
controversial either; it's inane. <dw>


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 E2MD Working Group is chartered to develop a new Dynamic
    Delegation Discovery System (DDDS) application E2MD, 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.
<dw>Zooks! This sounds like a big job, developing a Whole New System.  
Would just adding some resource records to the DNS that encode  
specific items of metadata suffice? IS "metadata" an unbounded  
representation space, or is it scoped to specific items (perhaps  
extensible through more RFCs and an IANA registry?</dw>

    E2MD 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 E2MD DDDS application a new IANA registry will be
    specified for registration of E2MD services. The registration policy
    shall be Expert Review and Specification Required (see RFC 5226),
    similarly as specified for Enumservice registrations.
<dw>Not sure I like this; I can see a registry for new resource- 
records or subfields thereof (services? Gimme a vocabulary break!) but  
I'm guessing we need more than Expert Review to protect the security/ 
privacy sensitivity aspects.</dw>

    The E2MD specifications shall reuse as much as possible from the  
ENUM
    DDDS and its IANA registry specification.

    Limitations of the DNS are to be considered while defining the
    protocol; in particular packet size restrictions of deployed DNS
    transport.

    The E2MD Working Group may take on further proposals for E2MD  
service
    registrations (e.g. send-n) until the IANA registration for E2MD
    services is approved by the IESG.


Out-Of-Scope

    E2MD shall not be specified as a general purpose lookup nor as bulk
    transfer protocol, but rather focus on clear use cases related to
    E.164 numbers.


Goals and Milestones:

    Aug 2010  Submit Internet Draft(s) for the E2MD DDDS application and
              its IANA registry specification to IESG

    Dec 2010  Submit 'cnam' and 'unused' as E2MD service registrations
              (Informational) to IESG

    XXX 2011  Close the E2MD Working Group (or recharter)


Internet-Drafts:

    http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02
    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