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

Paul Kyzivat <pkyzivat@cisco.com> Wed, 16 December 2009 14:33 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1633A67B3 for <dispatch@core3.amsl.com>; Wed, 16 Dec 2009 06:33:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA8r61jMTtI4 for <dispatch@core3.amsl.com>; Wed, 16 Dec 2009 06:33:34 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2AE9F3A67EE for <dispatch@ietf.org>; Wed, 16 Dec 2009 06:33:34 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjMGAKd+KEurRN+J/2dsb2JhbACYeaYMlxGCLwSBeASNTg
X-IronPort-AV: E=Sophos;i="4.47,406,1257120000"; d="scan'208";a="280453455"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 16 Dec 2009 14:33:20 +0000
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nBGEXJBW014582; Wed, 16 Dec 2009 14:33:20 GMT
Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:33:19 -0500
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:33:19 -0500
Message-ID: <4B28EFAF.7060203@cisco.com>
Date: Wed, 16 Dec 2009 09:33:19 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Richard Shockey <richard@shockey.us>
References: <alpine.DEB.2.00.0912152025000.6395@softronics.hoeneisen.ch> <015b01ca7dc0$becf4d10$3c6de730$@us>
In-Reply-To: <015b01ca7dc0$becf4d10$3c6de730$@us>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Dec 2009 14:33:19.0406 (UTC) FILETIME=[B64CD4E0:01CA7E5C]
Cc: 'IETF DISPATCH list' <dispatch@ietf.org>
Subject: Re: [dispatch] E2M: Proposed Charter (draft version only)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Dec 2009 14:33:35 -0000

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
>