From mailnull@www1.ietf.org Fri Nov 1 17:16:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06648 for ; Fri, 1 Nov 2002 17:16:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1MI9608734 for enum-archive@odin.ietf.org; Fri, 1 Nov 2002 17:18:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1MHxv08724; Fri, 1 Nov 2002 17:17:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1MGVv08668 for ; Fri, 1 Nov 2002 17:16:31 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06598 for ; Fri, 1 Nov 2002 17:14:00 -0500 (EST) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA1MGOb27491 for ; Fri, 1 Nov 2002 22:16:24 GMT Message-Id: <5.1.0.14.2.20021101171551.023ece20@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Nov 2002 17:16:58 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: I-D ACTION:draft-brunner-epp-data-considerations-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This draft may have some relevance for those of you working on ENUM trials and issues surrounding provisioning of the global ENUM system. >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-brunner-epp-data-considerations-00.txt >Date: Fri, 01 Nov 2002 08:41:19 -0500 >Sender: owner-ietf-announce@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : EPP Data Considerations > Author(s) : E. Brunner-Williams > Filename : draft-brunner-epp-data-considerations-00.txt > Pages : 16 > Date : 2002-10-31 > >This memo discusses data collection considerations and EPP. It is >far from complete, but deadlines press. >Distribution of this document is unlimited. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-brunner-epp-data-considerations-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-brunner-epp-data-considerations-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-brunner-epp-data-considerations-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2002-10-31150038.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-brunner-epp-data-considerations-00.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Nov 4 10:32:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18025 for ; Mon, 4 Nov 2002 10:32:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4FYSi32716 for enum-archive@odin.ietf.org; Mon, 4 Nov 2002 10:34:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4FYDv32701; Mon, 4 Nov 2002 10:34:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4FOav32222 for ; Mon, 4 Nov 2002 10:24:36 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17647 for ; Mon, 4 Nov 2002 10:22:05 -0500 (EST) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA4FOXb31556 for ; Mon, 4 Nov 2002 15:24:33 GMT Message-Id: <5.1.0.14.2.20021104102331.041b8f18@wheresmymailserver.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Nov 2002 10:23:58 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] some general thoughts on enumservice compendium Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , my mailer seems to have a problem with "e" vs "i" this got sent to the general IETF list again .. *** Atlanta is coming up and I'd like to see a more structured and focused discussion of the issues surrounding this draft and its relationship to the h.323 and SIP registration draft ...in addition it can be assumed that the FAX WG and VPIM WG have their own thoughts about how these issues should be treated. In the first order of business I'd like to get WG consensus that both the Levin H.323 registration draft and the SIP registration draft should be ENUM WG documents immediately. I think these are necessary for upcoming trials etc and if we have consensus now that is one item we do not need to deal with in Atlanta. Second IMHO (personal opinion here) the general concept in the enumservice compendium document seem to be the concept of descriptors or hints as to the nature, possible location and function of a particular end point. That said I'm wondering if we can separate the issue here to a more generic enumservice concept and enumservice descriptor. E2U+enumservice:enumservicedescriptor:enumservicedescriptor:etc. There are complications here since IMHO E2U+fax and E2U+tel:fax might be considered the same thing. Obviously E2U+sip and E2U+sip:voice are the same etc. Wearing my WG Chair hat ..I'm not going to say that one syntax is better that the other ..as some of you may have noted in my Security and Privacy issues draft I at least postulate that both the minimalist and maximum views of the issue have practical uses. I havent seen any comments on my draft ..so Thoughts etc? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Nov 4 13:11:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26480 for ; Mon, 4 Nov 2002 13:11:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4IDRd12346 for enum-archive@odin.ietf.org; Mon, 4 Nov 2002 13:13:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4IDPv12341; Mon, 4 Nov 2002 13:13:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4ICAv12280 for ; Mon, 4 Nov 2002 13:12:10 -0500 Received: from hall.mail.mindspring.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26389 for ; Mon, 4 Nov 2002 13:09:39 -0500 (EST) Received: from user-2ivel3m.dialup.mindspring.com ([165.247.84.118] helo=dick.ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 188lhl-0000lz-00 for enum@ietf.org; Mon, 04 Nov 2002 13:12:05 -0500 Message-Id: <5.1.0.14.2.20021104131111.03e27cf8@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Nov 2002 13:11:21 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: I-D ACTION:draft-levin-enum-h323-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-levin-enum-h323-00.txt >Date: Mon, 04 Nov 2002 10:04:10 -0500 >Sender: owner-ietf-announce@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : ENUM Service Registration for H.323 URL > Author(s) : O. Levin > Filename : draft-levin-enum-h323-00.txt > Pages : 4 > Date : 2002-11-1 > >The H.323 specification [2] defines a means for building multimedia >communication services over an arbitrary Packet Based Network, >including the Internet. This document registers an ENUM service for >H.323 according to specifications and guidelines in RFC2916bis [3]. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-levin-enum-h323-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-levin-enum-h323-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-levin-enum-h323-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2002-11-1143059.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-levin-enum-h323-00.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Nov 5 09:19:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19753 for ; Tue, 5 Nov 2002 09:19:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5EL1t14402 for enum-archive@odin.ietf.org; Tue, 5 Nov 2002 09:21:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5EKvv14396; Tue, 5 Nov 2002 09:20:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5EJnv14309 for ; Tue, 5 Nov 2002 09:19:49 -0500 Received: from tree.nask.waw.pl (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19689 for ; Tue, 5 Nov 2002 09:17:17 -0500 (EST) Received: from anbar (andbart.nask.waw.pl [193.59.204.115]) by tree.nask.waw.pl (8.11.6/8.9.3) with ESMTP id gA5EIrM61735; Tue, 5 Nov 2002 15:18:53 +0100 (CET) (envelope-from ANDRZEJB@NASK.PL) From: "Andrew Bartosiewicz" To: , Date: Tue, 5 Nov 2002 15:18:42 +0100 Message-ID: <002401c284d6$3f9d0cc0$73cc3bc1@nask.waw.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <62DA45D4963FA747BA1B253E266760F903F7B270@OCCLUST04EVS1.ugd.att.com> Content-Transfer-Encoding: 7bit Subject: [Enum] using ENUM for numbers poratbility Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm trying to find out about using ENUM for number portability in PSTN. Is there any country using ENUM as central database for ported numbers? Andrew Bartosiewicz NASK _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Nov 5 09:30:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20375 for ; Tue, 5 Nov 2002 09:30:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5EW4j15105 for enum-archive@odin.ietf.org; Tue, 5 Nov 2002 09:32:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5EW4v15096; Tue, 5 Nov 2002 09:32:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5EV2v15040 for ; Tue, 5 Nov 2002 09:31:02 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20184 for ; Tue, 5 Nov 2002 09:28:31 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Nov 2002 15:33:56 +0100 Message-ID: <06CF906FE3998C4E944213062009F16202BD16@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: using ENUM for numbers poratbility Thread-Index: AcKE1w+wU334lkAoTFSeDGr5CCub3QAAHPjQ From: "Stastny Richard" To: "Andrew Bartosiewicz" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA5EV2v15041 Subject: [Enum] RE: using ENUM for numbers poratbility Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Not yet, as far is I know. But ETSI SPAN11_NAR has a work item dealing with these issues. Richard Statsny > -----Original Message----- > From: Andrew Bartosiewicz [mailto:ANDRZEJB@NASK.PL] > Sent: Tuesday, November 05, 2002 3:19 PM > To: enum@ietf.org; enum-trials@ripe.net > Subject: using ENUM for numbers poratbility > > > I'm trying to find out about using ENUM for number > portability in PSTN. > Is there any country using ENUM as central database for > ported numbers? > > Andrew Bartosiewicz > NASK > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Nov 5 09:30:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20388 for ; Tue, 5 Nov 2002 09:30:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5EW6J15136 for enum-archive@odin.ietf.org; Tue, 5 Nov 2002 09:32:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5EW6v15131; Tue, 5 Nov 2002 09:32:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5EVSv15052 for ; Tue, 5 Nov 2002 09:31:28 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20192 for ; Tue, 5 Nov 2002 09:28:57 -0500 (EST) Received: from dick.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id GAA07309; Tue, 5 Nov 2002 06:31:03 -0800 Message-Id: <5.1.0.14.2.20021105092918.0448ac08@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Nov 2002 09:30:19 -0500 To: "Andrew Bartosiewicz" , , From: Richard Shockey In-Reply-To: <002401c284d6$3f9d0cc0$73cc3bc1@nask.waw.pl> References: <62DA45D4963FA747BA1B253E266760F903F7B270@OCCLUST04EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Re: using ENUM for numbers poratbility Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 03:18 PM 11/5/2002 +0100, Andrew Bartosiewicz wrote: >I'm trying to find out about using ENUM for number portability in PSTN. >Is there any country using ENUM as central database for ported numbers? Its been discussed in various forums and is technically feasable ..but the answer is no. my colleague James Yu has a ID on how to include NP data in a TEL URL. >Andrew Bartosiewicz >NASK >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Nov 5 15:37:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12487 for ; Tue, 5 Nov 2002 15:37:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5Kdwq07773 for enum-archive@odin.ietf.org; Tue, 5 Nov 2002 15:39:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Kdov07768; Tue, 5 Nov 2002 15:39:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Kcmv07743 for ; Tue, 5 Nov 2002 15:38:48 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12406 for ; Tue, 5 Nov 2002 15:36:15 -0500 (EST) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA5Kcgb17181 for ; Tue, 5 Nov 2002 20:38:43 GMT Message-Id: <5.1.0.14.2.20021105153616.02a04d88@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Nov 2002 15:37:06 -0500 To: enum@ietf.org From: Richard Shockey Subject: [Enum] Last Call Agenda for ENUM WG IETF 55 Atlanta GA. Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA5Kcmv07744 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I want a last call on this agenda .... are we OK with it? Any additions etc? ############### MONDAY, November 18, 2002 1130-1300 Break 1300-1500 Afternoon Sessions I TSV enum Telephone Number Mapping WG Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) Scribe Introduction … I am looking for a scribe ? VOLUNTEERS WANTED ASAP !!! It is my sad duty to report that our long standing scribe Jay Hilton is no longer with Telcordia and will not be attending IETF Atlanta. 1. RFC2916bis -0x REV - Faltstrom/Mealing (45 Min) ############### 2. J.Peterson (20min) Enumservice registration for SIP Addresses-of Record - Using ENUM for SIP applications Not yet posted to ID editors. ############### 3. R.Bradner &Co [20 Min ???] We definitely need to come to some consensus on how to work this issue. Title : 'A compendium of enumservice registrations' Author(s) : R. Brandner et al. Filename : draft-brandner-enumservices-compendium-00.txt Pages : 0 Date : 2002-9-16 This document includes a basic set of enumservice descriptions that are intended for use in deployments of ENUM. These descriptions form a set of enumservice registration requests, as laid out in section 3 of draft-ietf-enum-rfc2916bis-01.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservices-compendium-00.txt ################ 3. The 'enum' URI (L. Conroy 15 min) We discussed this some in Yokohama but did not come to a definitive conclusion whether this URI was appropriate or some extension to the TEL URL was sufficient. http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-00.txt 4. Open Discussion ... A. The Reverse ENUM issue .... I'd like to hear some more views on this. Does this need to be standardized? It seems to come up on the list with some regularity. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Nov 5 16:57:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18096 for ; Tue, 5 Nov 2002 16:57:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5LxVC12543 for enum-archive@odin.ietf.org; Tue, 5 Nov 2002 16:59:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5LxSv12535; Tue, 5 Nov 2002 16:59:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Lwnv12510 for ; Tue, 5 Nov 2002 16:58:49 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18037 for ; Tue, 5 Nov 2002 16:56:15 -0500 (EST) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA5Lwgb20048 for ; Tue, 5 Nov 2002 21:58:42 GMT Message-Id: <5.1.0.14.2.20021028142408.041cadd0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Nov 2002 16:59:17 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA5Lwov12511 Subject: [Enum] Proposed Final Agenda for ENUM WG - IETF 55 Atlanta - Version 2 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit MONDAY, November 18, 2002 1130-1300 Break 1300-1500 Afternoon Sessions I TSV enum Telephone Number Mapping WG Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) Scribe Introduction … I am looking for a scribe ? VOLUNTEERS WANTED ASAP !!! PLEASE Volunteer now ... prizes offered. 1. RFC2916bis -0x REV - Faltstrom/Mealing (45 Min) I'm assuming its coming... Patrik ? ############### 2. J.Peterson ( 15 min ) Title : enumservice registration for SIP Addresses-of-Record Author(s) : J. Peterson Filename : draft-peterson-enum-sip-00.txt Pages : 16 Date : 2002-10-29 This document registers an ENUM service for SIP (the Session Initiation Protocol), pursuant to the guidelines in RFC2916bis. Specifically, this document focuses on provisioning SIP addresses-of- record in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-peterson-enum-sip-00.txt #################### 3. O. Levin ( 15 min ) >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : ENUM Service Registration for H.323 URL > Author(s) : O. Levin > Filename : draft-levin-enum-h323-00.txt > Pages : 4 > Date : 2002-11-1 > >The H.323 specification [2] defines a means for building multimedia >communication services over an arbitrary Packet Based Network, >including the Internet. This document registers an ENUM service for >H.323 according to specifications and guidelines in RFC2916bis [3]. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-levin-enum-h323-00.txt ############### 3. R. Stastny &Co on behalf of R. Brandner [ 20 Min ] We definitely need to come to some consensus on how to work this issue. Title : 'A compendium of enumservice registrations' Author(s) : R. Brandner et al. Filename : draft-brandner-enumservices-compendium-00.txt Pages : 0 Date : 2002-9-16 This document includes a basic set of enumservice descriptions that are intended for use in deployments of ENUM. These descriptions form a set of enumservice registration requests, as laid out in section 3 of draft-ietf-enum-rfc2916bis-01.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservices-compendium-00.txt #################################### 4. R. Shockey (10 M ) >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-shockey-enum-privacy-security-00.txt >Date: Thu, 31 Oct 2002 06:13:03 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Privacy and Security Considerations in ENUM > Author(s) : R. Shockey > Filename : draft-shockey-enum-privacy-security-00.txt > Pages : 12 > Date : 2002-10-30 > >Many individuals and groups have expressed concerns about the >privacy and security of personal information to be established in >implementations of RFC 2916. This document discusses some of the >technical as well as security and privacy considerations national >implementations of ENUM should consider. >This is a work in progress. Input from security and privacy >experts is welcome. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-shockey-enum-privacy-security-00.txt ################ 4. (L. Conroy 15 min) The 'enum' URI We discussed this some in Yokohama but did not come to a definitive conclusion whether this URI was appropriate or some extension to the TEL URL was sufficient. We should come to some consensus on this. http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-00.txt 5. Open Discussion ... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Nov 6 15:37:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11159 for ; Wed, 6 Nov 2002 15:37:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6KdAQ10581 for enum-archive@odin.ietf.org; Wed, 6 Nov 2002 15:39:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Kd0v10574; Wed, 6 Nov 2002 15:39:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Kbnv10530 for ; Wed, 6 Nov 2002 15:37:49 -0500 Received: from granger.mail.mindspring.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11089 for ; Wed, 6 Nov 2002 15:35:15 -0500 (EST) Received: from user-uiveq2f.dsl.mindspring.com ([165.247.104.79] helo=dick.ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 189Wvm-0001Qr-00; Wed, 06 Nov 2002 15:37:42 -0500 Message-Id: <5.1.0.14.2.20021106153527.03cc9df8@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Nov 2002 15:37:13 -0500 To: enum@ietf.org From: Richard Shockey Cc: ietf-provreg@cafax.se Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] EC Directive on Privacy in the Electronics Communications Sector Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Some relevance to ENUM - Provreg provisioning.... http://europa.eu.int/eur-lex/pri/en/oj/dat/2002/l_201/l_20120020731en00370047.pdf >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Nov 6 21:16:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20057 for ; Wed, 6 Nov 2002 21:16:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA72I5Q29685 for enum-archive@odin.ietf.org; Wed, 6 Nov 2002 21:18:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA72Hvv29669; Wed, 6 Nov 2002 21:17:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA72GLv29626 for ; Wed, 6 Nov 2002 21:16:21 -0500 Received: from mclean.mail.mindspring.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19958; Wed, 6 Nov 2002 21:13:44 -0500 (EST) Received: from user-uivench.dsl.mindspring.com ([165.247.93.145] helo=dick.ix.netcom.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 189cDK-0001lr-00; Wed, 06 Nov 2002 21:16:11 -0500 Message-Id: <5.1.0.14.2.20021106102217.03e73ae8@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Nov 2002 21:13:54 -0500 To: enum@ietf.org From: Richard Shockey Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Final Agenda for ENUM WG - IETF 55 Atlanta Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , MONDAY, November 18, 2002 1130-1300 Break 1300-1500 Afternoon Sessions I TSV enum Telephone Number Mapping WG Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) 1. RFC2916bis -0x REV - Faltstrom/Mealing (45 Min) Status Update.. ################## Agenda NOTE: The unresolved issues in the WG all relate in one way or another to the structure of the enumservice field and what information should or should not be included and in which order. In particular I'd like to see a focus on service vs description. The fundamental goal of the meeting should be to clarify and hopefully settle the issue. Items 2-4 directly address these issues and 5 provides a marginal perspective. ############### 2. J.Peterson ( 15 min ) Title : enumservice registration for SIP Addresses-of-Record Author(s) : J. Peterson Filename : draft-peterson-enum-sip-00.txt Pages : 16 Date : 2002-10-29 This document registers an ENUM service for SIP (the Session Initiation Protocol), pursuant to the guidelines in RFC2916bis. Specifically, this document focuses on provisioning SIP addresses-of- record in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-peterson-enum-sip-00.txt #################### 3. O. Levin ( 15 min ) ENUM Service Registration for H.323 URL Author(s) : O. Levin Filename : draft-levin-enum-h323-00.txt Pages : 4 Date : 2002-11-1 The H.323 specification [2] defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers an ENUM service for H.323 according to specifications and guidelines in RFC2916bis [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levin-enum-h323-00.txt ############### 4. R. Stastny & Co on behalf of R. Brandner [ 20 Min ] Title : 'A compendium of enumservice registrations' Author(s) : R. Brandner et al. Filename : draft-brandner-enumservices-compendium-00.txt Pages : 0 Date : 2002-9-16 This document includes a basic set of enumservice descriptions that are intended for use in deployments of ENUM. These descriptions form a set of enumservice registration requests, as laid out in section 3 of draft-ietf-enum-rfc2916bis-01.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservices-compendium-00.txt #################################### 5. R. Shockey (10 M ) Title : Privacy and Security Considerations in ENUM Author(s) : R. Shockey Filename : draft-shockey-enum-privacy-security-00.txt Pages : 12 Date : 2002-10-30 Many individuals and groups have expressed concerns about the privacy and security of personal information to be established in implementations of RFC 2916. This document discusses some of the technical as well as security and privacy considerations national implementations of ENUM should consider. This is a work in progress. Input from security and privacy experts is welcome. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shockey-enum-privacy-security-00.txt I'm looking for additional comments on directions this draft should take ################ 4. L. Conroy 15 min The 'enum' URI We discussed this some in Yokohama but did not come to a definitive conclusion whether this URI was appropriate or some extension to the TEL URL was sufficient. NOTE on Management issue: The IPTEL WG has now assumed responsibility for all telephony related URI development including the TEL URL itself. Whether this draft even remains in the ENUM WG is now an issue. After polling the IPTEL Chairs we can revisit the issues in the ENUM WG due to time constraints...however the proper place for this draft in the future will have to be clarified. http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-00.txt 5. Open Discussion ... A. Reverse ENUM? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 7 05:06:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08686 for ; Thu, 7 Nov 2002 05:06:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7A80l01551 for enum-archive@odin.ietf.org; Thu, 7 Nov 2002 05:08:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7A7vv01544; Thu, 7 Nov 2002 05:07:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7A6tv00887 for ; Thu, 7 Nov 2002 05:06:55 -0500 Received: from babelfish.srmr.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08673; Thu, 7 Nov 2002 05:04:25 -0500 (EST) Received: from babelfish.srmr.co.uk [193.118.205.14] by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 2065u via TCP with SMTP; Thu, 07 Nov 2002 10:06:47 +0000 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <5.1.0.14.2.20021106102217.03e73ae8@popd.ix.netcom.com> References: <5.1.0.14.2.20021106102217.03e73ae8@popd.ix.netcom.com> Date: Thu, 7 Nov 2002 10:06:49 +0000 To: Richard Shockey , enum@ietf.org From: Lawrence Conroy Subject: Re: [Enum] Final Agenda for ENUM WG - IETF 55 Atlanta Cc: agenda@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 9:13 pm -0500 6/11/02, Richard Shockey wrote: >MONDAY, November 18, 2002 > >1130-1300 Break >1300-1500 Afternoon Sessions I > >TSV enum Telephone Number Mapping WG >NOTE on Management issue: The IPTEL WG has now assumed >responsibility for all telephony related URI development including >the TEL URL itself. Whether this draft even remains in the ENUM WG >is now an issue. After polling the IPTEL Chairs we can revisit the >issues in the ENUM WG due to time constraints...however the proper >place for this draft in the future will have to be clarified. > http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-00.txt I'm trying to see where in the draft it says that this is a telephony URL. It does say that it's intended ONLY to trigger an ENUM lookup (i.e. in DNS) and NOT trigger a phone call. One could equally say that dap is a telephony URL. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 7 09:31:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25864 for ; Thu, 7 Nov 2002 09:31:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7EXbt20948 for enum-archive@odin.ietf.org; Thu, 7 Nov 2002 09:33:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7EXUv20936; Thu, 7 Nov 2002 09:33:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7EWlv20903 for ; Thu, 7 Nov 2002 09:32:47 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25835 for ; Thu, 7 Nov 2002 09:30:16 -0500 (EST) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA7EWjb08941 for ; Thu, 7 Nov 2002 14:32:45 GMT Message-Id: <5.1.0.14.2.20021107092803.047a5270@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Nov 2002 09:28:18 -0500 To: enum@ietf.org From: Internet-Drafts@ietf.org (by way of Richard Shockey ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] I-D ACTION:draft-levin-iptel-h323-url-scheme-05.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : H.323 URL Scheme Registration with IANA Author(s) : O. Levin Filename : draft-levin-iptel-h323-url-scheme-05.txt Pages : 6 Date : 2002-11-6 This IETF document reproduces the H323-URL definition found in ITU-T Recommendation H.323 [3] and is published as an RFC for ease of access and IANA registration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levin-iptel-h323-url-scheme-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-levin-iptel-h323-url-scheme-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-levin-iptel-h323-url-scheme-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2002-11-6174137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-levin-iptel-h323-url-scheme-05.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 7 10:33:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28333 for ; Thu, 7 Nov 2002 10:33:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7FZoq25591 for enum-archive@odin.ietf.org; Thu, 7 Nov 2002 10:35:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7FZiv25586; Thu, 7 Nov 2002 10:35:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7FWQv25378 for ; Thu, 7 Nov 2002 10:32:26 -0500 Received: from babelfish.srmr.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28197 for ; Thu, 7 Nov 2002 10:29:54 -0500 (EST) Received: from babelfish.srmr.co.uk [193.118.205.14] by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 2086u via TCP with SMTP; Thu, 07 Nov 2002 15:32:17 +0000 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Thu, 7 Nov 2002 15:32:19 +0000 To: enum@ietf.org From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] SIP as SRS questions Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi folks, I've been trying to understand how SIP works as a Service Resolution Service. As a core feature, SIP allows a user to register a number of different kinds of URIs "behind" a single Address of Record. This is neat, as it looks like SIP is the core of an ENUM SRS. BUT...I have some questions on the detailed mechanisms. (i) The callee can decide what URIs they register. However, how does this SIP subscriber specify the features/teleservices with which each of these URIs is associated? (ii) How does the caller specify the features/teleservices in which they are willing to engage? (This is what we have in the past called their "services of interest"). I *think* that this involves SIP callerprefs (specifically feature-lists), but am not sure. Can anyone confirm that this is how the SIP feature/teleservice negotiation is done? As a final plea, could we have a quick run-through of this at the ATL ENUM meeting - it doesn't seem to be obvious from the drafts, and is a key issue, IMHO. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 7 11:19:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00559 for ; Thu, 7 Nov 2002 11:19:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7GLOB28946 for enum-archive@odin.ietf.org; Thu, 7 Nov 2002 11:21:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7GLNv28937; Thu, 7 Nov 2002 11:21:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7GKRv28858 for ; Thu, 7 Nov 2002 11:20:27 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00493; Thu, 7 Nov 2002 11:17:55 -0500 (EST) Received: from dick.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA27433; Thu, 7 Nov 2002 08:20:07 -0800 Message-Id: <5.1.0.14.2.20021107110621.046b6768@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Nov 2002 11:20:38 -0500 To: enum@ietf.org From: Richard Shockey Cc: iptel@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] A note from your ENUM WG chairs .... Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Patrik and I have reviewed the issue of this document and have consulted extensively with the Area Directors. The Area Directors have asked the IPTEL WG to assume all responsibility for telephony related URI schemes which will include the TEL URL and the H.323 URL scheme etc. In this context we believe this document properly belongs in IPTEL and therefore is "out of scope" for the ENUM WG. The ENUM WG will continue to be responsible for enumservice registration documents not directly under consideration by a specific WG ( aka fax,vpim). After consulting with the IPTEL chairs they have a full schedule of their own and will not be able to discuss this document there there. So... we _will_ allocate time in Atlanta to review this document one more time after which is will need to go to IPTEL. ############################# The 'enum' URI http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-00.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 7 12:15:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02647 for ; Thu, 7 Nov 2002 12:15:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7HHGQ00766 for enum-archive@odin.ietf.org; Thu, 7 Nov 2002 12:17:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7HHEv00761; Thu, 7 Nov 2002 12:17:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7HGsv00739 for ; Thu, 7 Nov 2002 12:16:54 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02607 for ; Thu, 7 Nov 2002 12:14:20 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.7]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gA7HGlYH026193; Thu, 7 Nov 2002 12:16:50 -0500 (EST) Message-ID: <3DCA9FFD.8020005@dynamicsoft.com> Date: Thu, 07 Nov 2002 12:16:45 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lawrence Conroy CC: enum@ietf.org Subject: Re: [Enum] SIP as SRS questions References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Lawrence Conroy wrote: > Hi folks, > I've been trying to understand how SIP works as a Service Resolution > Service. > As a core feature, SIP allows a user to register a number of different > kinds of > URIs "behind" a single Address of Record. This is neat, as it looks like > SIP is > the core of an ENUM SRS. BUT...I have some questions on the detailed > mechanisms. > > (i) The callee can decide what URIs they register. However, how does > this SIP > subscriber specify the features/teleservices with which each of these > URIs is > associated? Through the caller preferences specification: http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-06.txt which allows a UA to include capabilities and other information as part of its registration. For example, a UA can say "this UA does audio, video and supports these SIP methods". > > (ii) How does the caller specify the features/teleservices in which they > are willing > to engage? (This is what we have in the past called their "services of > interest"). > I *think* that this involves SIP callerprefs (specifically feature-lists), > but am not sure. > Can anyone confirm that this is how the SIP feature/teleservice > negotiation is done? Yes, but not just with caller prefs. The caller can include explicit preferences, such as "route this request to the UA that supports audio and video and is a voicemail server". Caller prefs provides headers for doing that (Accept-Contact, Reject-Contact). However, connecting a caller to a callee is a two party problem. Both participants have preferences. The caller might want an audio call, but the callee has preferences too - that they want audio calls to go to their cell phone. This is handled genreally through routing applications that run in the domain of the callee. THose can be supported through things like CPL, servlets, CGI and even more tradtitional APIs like JCC and Parlay, which would run ontop of SIP proxies. How the caller preferences and callee logic are combined is a matter of local policy. hth, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 7 13:28:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05364 for ; Thu, 7 Nov 2002 13:28:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7IUm805279 for enum-archive@odin.ietf.org; Thu, 7 Nov 2002 13:30:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7IUiv05274; Thu, 7 Nov 2002 13:30:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7ITBv05203 for ; Thu, 7 Nov 2002 13:29:11 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05265 for ; Thu, 7 Nov 2002 13:26:36 -0500 (EST) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA7IT6b15211 for ; Thu, 7 Nov 2002 18:29:06 GMT Message-Id: <5.1.0.14.2.20021107132820.025934b8@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Nov 2002 13:29:48 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] A good reminder of what IETF WG Meetings are about Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , I would appreciate if everyone presenting in Atlanta kept these principals in mind. It is not the purpose of a WG session to have presentation of the content of a document. It is assumed that all attendees will have read the drafts in advance of the meeting. For documents that are work-in-progress, the presentation should cover issues resolved since the last draft followed by open issues and controversial topics with the intent to reach a resolution of said issues and topics. For new work items, the presentation should focus on what the problem is and why it is necessary for the work group to address it. Further it should be either shown how it falls within the existing charter or why and how the charter should be extended to encompass it. The solution should only be sketched. The appropriate way of bringing new work to the working group is to send a draft to the mailing list and promoting discussion on the list. Slots on the agenda should be used to discuss outstanding topics that has not be solved on the mailing list. For new proposals addressing issues where work-in-progess the presentation should focus on the (perceived) short-fallings of the existing work and why those issues need to be addressed both in terms of why they are required and why they cannot be addressed in the existing work. the new work must be related to existing work (i.e. compatible, mutually exclusive, outright replacement). Finally, the new solution should be skechted, explaining how the solution overcomes those issues. The primary purpose of this last part is to allow commentary from the floor, it should not be orientented toward selling the idea. In all cases only a limited number of slides should be used. Speakers should budget their at least 25% of their time to allow for questions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 7 13:41:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05677 for ; Thu, 7 Nov 2002 13:41:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7IhGo06397 for enum-archive@odin.ietf.org; Thu, 7 Nov 2002 13:43:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7IhFv06392; Thu, 7 Nov 2002 13:43:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7IfCv06288 for ; Thu, 7 Nov 2002 13:41:12 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05634 for ; Thu, 7 Nov 2002 13:38:37 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.7]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gA7If8YH026247; Thu, 7 Nov 2002 13:41:08 -0500 (EST) Message-ID: <3DCAB3C2.60704@dynamicsoft.com> Date: Thu, 07 Nov 2002 13:41:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: Lawrence Conroy , enum@ietf.org Subject: Re: [Enum] SIP as SRS questions References: <15A2739B7DAA624D8091C65981D7DA815EB38F@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit more inline. Peterson, Jon wrote: > inline. > > Jon Peterson > NeuStar, Inc. > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: Thursday, November 07, 2002 9:17 AM >>To: Lawrence Conroy >>Cc: enum@ietf.org >>Subject: Re: [Enum] SIP as SRS questions >> >> > > [snip] > >>>(ii) How does the caller specify the features/teleservices in which they >> > >>>are willing >>>to engage? (This is what we have in the past called their "services of >>>interest"). >> >>Yes, but not just with caller prefs. >>... [snip] > > > It is probably also worth mentioning the role that SDP plays in this > process. This isn't just a matter of the caller expressing general > preferences for communication to proxy servers - a lot of specific feature > negotiation takes place at the SDP level directly between the caller's user > agent and the callee's user agent(s). Very true, and very important for the topic at hand. Thanks for pointing this out, Jon. I'll also add to that some more. Negotiation on features occurs directly between agents during call setup time, but can also be done once the call is established. That is, once an audio call is set up, a user can renegotiate to add video, for example. This renegotiation can happen at both the SDP level and within SIP. For example, feature sets and capabilities can be renegotiated. When would this happen? One case is when a UA changes its logical role; morphing from a plain-old user agent into a conference server, for the purposes of supporting an ad-hoc conference. Such a change might result in renegotiation of capabilities and feature sets. I'm not sure how relevant it is, but worth noting. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 7 13:44:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05765 for ; Thu, 7 Nov 2002 13:44:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7Il3206553 for enum-archive@odin.ietf.org; Thu, 7 Nov 2002 13:47:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7Il3v06547; Thu, 7 Nov 2002 13:47:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7I9Av04422 for ; Thu, 7 Nov 2002 13:09:10 -0500 Received: from cypress.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04598 for ; Thu, 7 Nov 2002 13:06:35 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by cypress.neustar.com (8.11.6/8.11.6) with ESMTP id gA7I8wX03021; Thu, 7 Nov 2002 18:08:58 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 13:09:45 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB38F@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" , Lawrence Conroy Cc: enum@ietf.org Subject: RE: [Enum] SIP as SRS questions Date: Thu, 7 Nov 2002 13:09:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , inline. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, November 07, 2002 9:17 AM > To: Lawrence Conroy > Cc: enum@ietf.org > Subject: Re: [Enum] SIP as SRS questions > > [snip] > > > > (ii) How does the caller specify the features/teleservices in which they > > are willing > > to engage? (This is what we have in the past called their "services of > > interest"). > > Yes, but not just with caller prefs. > ... [snip] It is probably also worth mentioning the role that SDP plays in this process. This isn't just a matter of the caller expressing general preferences for communication to proxy servers - a lot of specific feature negotiation takes place at the SDP level directly between the caller's user agent and the callee's user agent(s). Finally, many features entail extension support. Extension negotiation includes the use of Require/Supported headers and the like. Support for particular extensions may be necessary to use features in intermediaries or endpoints (i.e. hBh or e2e). Incidentally, my SIP enumservice draft discusses (or at least mentions) caller preferences, SDP and extension support in this context. I'm happy to talk about this Atlanta, if there's some interest. > > hth, > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 7 15:41:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11114 for ; Thu, 7 Nov 2002 15:41:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7KhaU17574 for enum-archive@odin.ietf.org; Thu, 7 Nov 2002 15:43:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7KhWv17565; Thu, 7 Nov 2002 15:43:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7KZ2v15418 for ; Thu, 7 Nov 2002 15:35:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 Subject: [Enum] Note Well Statement Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 7 15:51:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11740 for ; Thu, 7 Nov 2002 15:51:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7Kr7118517 for enum-archive@odin.ietf.org; Thu, 7 Nov 2002 15:53:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7Kr5v18511; Thu, 7 Nov 2002 15:53:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7KqUv18474 for ; Thu, 7 Nov 2002 15:52:30 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11704 for ; Thu, 7 Nov 2002 15:49:56 -0500 (EST) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA7KqAb19396; Thu, 7 Nov 2002 20:52:10 GMT Message-Id: <5.1.0.14.2.20021107154432.02f83f20@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Nov 2002 15:52:44 -0500 To: "Peterson, Jon" , "'Jonathan Rosenberg'" , Lawrence Conroy From: Richard Shockey Subject: RE: [Enum] SIP as SRS questions Cc: enum@ietf.org In-Reply-To: <15A2739B7DAA624D8091C65981D7DA815EB38F@stntexch2.va.neusta r.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , A >Finally, many features entail extension support. Extension negotiation >includes the use of Require/Supported headers and the like. Support for >particular extensions may be necessary to use features in intermediaries or >endpoints (i.e. hBh or e2e). > >Incidentally, my SIP enumservice draft discusses (or at least mentions) >caller preferences, SDP and extension support in this context. I'm happy to >talk about this Atlanta, if there's some interest. please do it is additionally relevant to some observations I made in my Privacy and Security considerations ID. Privacy in the ENUM system is, in part ,about who controls how a communications session is to be established and what data is exposed necessary to create that session. I discussed the concept of a SRS as being particularly relevant in minimizing the amount of data exposed in the DNS. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 7 19:31:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19475 for ; Thu, 7 Nov 2002 19:31:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA80XfL00566 for enum-archive@odin.ietf.org; Thu, 7 Nov 2002 19:33:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA80XYv00545; Thu, 7 Nov 2002 19:33:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA80Wtv00509 for ; Thu, 7 Nov 2002 19:32:55 -0500 Received: from babelfish.srmr.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19441 for ; Thu, 7 Nov 2002 19:30:17 -0500 (EST) Received: from babelfish.srmr.co.uk [193.118.205.14] by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 2107u via TCP with SMTP; Fri, 08 Nov 2002 00:32:14 +0000 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <5.1.0.14.2.20021107154432.02f83f20@popd.ix.netcom.com> References: <5.1.0.14.2.20021107154432.02f83f20@popd.ix.netcom.com> Date: Fri, 8 Nov 2002 00:32:15 +0000 To: Richard Shockey , "Peterson, Jon" , "'Jonathan Rosenberg'" From: Lawrence Conroy Subject: RE: [Enum] SIP as SRS questions Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 3:52 pm -0500 7/11/02, Richard Shockey wrote: >A >>Finally, many features entail extension support. Extension negotiation >>includes the use of Require/Supported headers and the like. Support for >>particular extensions may be necessary to use features in intermediaries or >>endpoints (i.e. hBh or e2e). >> >>Incidentally, my SIP enumservice draft discusses (or at least mentions) >>caller preferences, SDP and extension support in this context. I'm happy to >>talk about this Atlanta, if there's some interest. > > >please do it is additionally relevant to some observations I made in >my Privacy and Security considerations ID. > >Privacy in the ENUM system is, in part ,about who controls how a >communications session is to be established and what data is exposed >necessary to create that session. > >I discussed the concept of a SRS as being particularly relevant in >minimizing the amount of data exposed in the DNS. Hi Folks, To which I add my thanks for these mails. Very useful. * Jon, could you spell out what features require extensions (other than requiring callerprefs itself, of course)? Is there an example where a feature list requires extensions? I didn't see this in the sip-02 draft. I'm being dense here, but... Also, I have one issue in the way that callerpref feature lists will be used with SIP users. * Jonathon, it seems that callerprefs feature lists are similar in spirit to the compendium draft - a way for the caller and callee to agree on the feature/"teleservice". The cluster of different elements listed in section 7 of callerprefs-06, taken together, can specify a communications resource capability in some detail. However, this seems VERY different from the enumservice definition template in 2916bis. How do the SIP registrant and the caller agree on a common set of feature strings for a given feature/"teleservice"? all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Nov 8 07:14:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14127 for ; Fri, 8 Nov 2002 07:14:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8CG2118487 for enum-archive@odin.ietf.org; Fri, 8 Nov 2002 07:16:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8CFuv18477; Fri, 8 Nov 2002 07:15:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8CEYv18430 for ; Fri, 8 Nov 2002 07:14:34 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14107 for ; Fri, 8 Nov 2002 07:12:01 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Nov 2002 13:17:29 +0100 Message-ID: <06CF906FE3998C4E944213062009F162024891@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Regarding brandner-compendium discussion in ATL Thread-Index: AcKHGkp8jKrD/P4DR6egSjPE256iTgAAE8hA From: "Stastny Richard" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA8CEZv18431 Subject: [Enum] Regarding brandner-compendium discussion in ATL Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, Now that the SIP and H323 enumservice drafts are published we need to update the "compendium" draft. Since both are describing enum services equivalent to the srs categorical enumservice, I propose to align the three IDs by changing the following sections of the as follows: -begin- 19. srs categorical enumservice 19.1. Description This category is used where the Registrant wants to use a specialised "Service Resolution Service" above and beyond ENUM. It can be used where the services available depend on factors that cannot be covered in the global ENUM system; for example, the services "advertised" may depend on the person asking, and so requires authentication to be performed before any detailed information is returned. 19.2. Comprised Services This category comprises THREE main services; dap, H323 and sip. Of these, the 'sip' service AND H323 has a rich feature sets and will be described in a separate documents. 19.3. Expected Client Behaviour If the end user has selected this as an "enumservice of interest" then the client should filter out all NAPTRs but those containing either the 'srs', 'sip', 'H323' or 'dap' tags, together with any NAPTRs showing the 'all' category and where the processed URIs indicate either "sip:", "H323" or "ldap:". If the Registrant has chosen to include only a NAPTR with either the 'srs' tag or that of one if its constituent enumservices, then the client can either initiate the "next stage" of service resolution directly, or report that this is required and await the end user's response. In either case, this is the end of ENUM processing; further evaluation continues using the features of the constructed URI. 19.4. Associated URIs At present, there are expected to be THREE URIs that can be associated with this category; "sip:", *H323" and "ldap:". -end- If there is any additional commments please let me know asap. In addition, I would like to mention, that the enumservices according the the draft-brandner-enumservices-compendium-00.txt have been implemented sucessfully in the Austrian ENUM Trial and the clients provided to the users. The trial is in operation since one month. Interested parties are invited to contact me for a demo in Atlanta and also may be provided with links download different available clients. best regards Richard Stastny _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 14 08:08:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17813 for ; Thu, 14 Nov 2002 08:08:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEDAGj27476 for enum-archive@odin.ietf.org; Thu, 14 Nov 2002 08:10:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEDA2v27469; Thu, 14 Nov 2002 08:10:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAED66v26791 for ; Thu, 14 Nov 2002 08:06:06 -0500 Received: from rsys000a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17753 for ; Thu, 14 Nov 2002 08:03:28 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <4SCZQ5RZ>; Thu, 14 Nov 2002 13:06:03 -0000 Received: from babelfish.srmr.co.uk (percy.roke.co.uk [193.118.192.111]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WLW94G7G; Thu, 14 Nov 2002 13:05:59 -0000 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Cc: jon.peterson@neustar.biz, michael.michael@neonym.net Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Thu, 14 Nov 2002 13:04:36 +0000 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Enum] "enum:" URI comments Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="us-ascii" ; format="flowed" Hi John, Michael, Folks, A long time ago, in a land far away, Jon said: At 4:55 pm -0500 3/9/02, Peterson, Jon wrote: >The ENUM URI in this case would be an opaque pointer >to a set of communications records, but this requirement could be fulfilled >by any number of existing URI schemes that have no bearing on telephone >numbers (I'm sure DDDS would allow this in any number of ways). Jon: I don't see what existing URI schemes can do this - if there is such a URI scheme that fulfills the "MUST check ENUM or die" requirement, then please holler and we can save some meeting time. Michael - our avowed D3S Wizard: I don't see how D3S can generate a "ENUM golden tree" FQDN. I did ask earlier, but was not specific enough. I understand that one can point out to some other domain space - it's the RegExp mechanism for creating a FQDN in e164.arpa that I can't get, particularly with an open number plan. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 14 13:17:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25967 for ; Thu, 14 Nov 2002 13:17:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEIJkK13739 for enum-archive@odin.ietf.org; Thu, 14 Nov 2002 13:19:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEIJev13734; Thu, 14 Nov 2002 13:19:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEIGVv13629 for ; Thu, 14 Nov 2002 13:16:31 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25937 for ; Thu, 14 Nov 2002 13:13:51 -0500 (EST) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gAEIGLb30401; Thu, 14 Nov 2002 18:16:21 GMT Message-Id: <5.2.0.9.2.20021114121620.0420a9c0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 14 Nov 2002 13:17:10 -0500 To: "Stastny Richard" , From: Richard Shockey Subject: Re: [Enum] Regarding brandner-compendium discussion in ATL In-Reply-To: <06CF906FE3998C4E944213062009F162024891@oefeg-s02.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , A. >19.2. Comprised Services >This category comprises THREE main services; dap, H323 and >sip. Of these, the 'sip' service AND H323 has a rich feature sets and >will be described in a separate documents. why cant you just call dap ldap? and I object to this concept _at this time_ since we have no formal protocol definition or schema or how LDAP might be used as a service resolution service. We have H.323 and SIP ... that seems fine for now. I'm not saying LDAP might not be useful if there was a formal definition, but I would then suggest an appropriate the enumservice tag would be E2U+ldap:srs >19.3. Expected Client Behaviour >If the end user has selected this as an "enumservice of interest" then >the client should filter out all NAPTRs but those containing either the >'srs', 'sip', 'H323' or 'dap' tags, together with any NAPTRs showing the >'all' >category and where the processed URIs indicate either "sip:", "H323" >or "ldap:". > >If the Registrant has chosen to include only a NAPTR with either the >'srs' You are not suggesting E2U+sip:srs are you ... or E2U+h323:srs ? why is this necessary? IMHO its self explanatory and redundant...its is the called parties proxy that will determine what and if any response is necessary. >tag or that of one if its constituent enumservices, then the client can >either initiate the "next stage" of service resolution directly, or >report >that this is required and await the end user's response. >In either case, this is the end of ENUM processing; further evaluation >continues using the features of the constructed URI. ok >19.4. Associated URIs >At present, there are expected to be THREE URIs that can be associated >with >this category; "sip:", *H323" and "ldap:". >-end- again since the LDAP concept is not defined it is not appropriate to put a place holder here. >If there is any additional commments please let me know asap. I wish we could sepererate the issues here into services and descriptions of services. What we will have is E2U+sip E2U+h323 what we will have shortly are probably E2U+fax and E2U+vpim The enumservice names in the compendium are 'talk', 'voice', 'ivoice', 'video', 'msg', 'fax', 'sms', 'ems', 'mms', 'email', 'chat', 'tp', 'im', 'info', 'web', 'ft', 'srs', and 'all' IMHO the general case is E2U+enumservice:enumdescription1:enumdescription2:etc where enumdescription is purely optional on the part of the ENUM registrant E2U+voice:sip is not acceptable E2U+sip:voice where "voice" is purely optional is. or E2U+sip:voice:home where "voice" and "home" are purely optional to the registrant if they are a real estate sales person .. E2U+sip:video may ..may make sense is certain cases.. I still do not understand the difference between "talk" and "voice" and "ivoice" I do not understand the difference between "chat" and "im" E2U+tel:fax makes sense, a PSTN fax call .. E2U+tel:mobile:sms makes sense .. E2U+tel:textphone seems very useful. etc I know you are not going to like this but I'm suggesting this is a direction we need to consider for this draft. >In addition, I would like to mention, that the enumservices according >the the draft-brandner-enumservices-compendium-00.txt >have been implemented sucessfully in the Austrian ENUM Trial and the >clients provided to the users. The trial is in operation since one >month. > >Interested parties are invited to contact me for a demo in Atlanta and >also may be provided with links download different available clients. Folks on the list ...this is a very useful and interesting client that Telecom Austria and Infonova have produced .. I suggest it is worth investigating. It help clarifies some of the rationale embodied within the compendium draft by seeing how enumservice description can be used ..I've been playing with it myself. do mail Richard if you are interested. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 14 13:35:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26360 for ; Thu, 14 Nov 2002 13:35:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEIc7G15156 for enum-archive@odin.ietf.org; Thu, 14 Nov 2002 13:38:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEIc6v15151; Thu, 14 Nov 2002 13:38:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEIZQv14493 for ; Thu, 14 Nov 2002 13:35:26 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26303 for ; Thu, 14 Nov 2002 13:32:46 -0500 (EST) Received: from cypress.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id gAEIYgi03895; Thu, 14 Nov 2002 18:34:42 GMT Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by cypress.neustar.com (8.11.6/8.11.6) with ESMTP id gAEIYbX14317; Thu, 14 Nov 2002 18:34:37 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Nov 2002 13:35:35 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB3CB@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Conroy, Lawrence (SMTP)'" , enum@ietf.org Cc: michael.michael@neonym.net Date: Thu, 14 Nov 2002 13:35:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] RE: "enum:" URI comments Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , I had thought this thread had relocated to iptel, but, a response inline. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > Sent: Thursday, November 14, 2002 5:05 AM > To: enum@ietf.org > Cc: jon.peterson@neustar.biz; michael.michael@neonym.net > Subject: "enum:" URI comments > > > Hi John, Michael, Folks, > > A long time ago, in a land far away, Jon said: > At 4:55 pm -0500 3/9/02, Peterson, Jon wrote: > >The ENUM URI in this case would be an opaque pointer > >to a set of communications records, but this requirement could be fulfilled > >by any number of existing URI schemes that have no bearing on telephone > >numbers (I'm sure DDDS would allow this in any number of ways). > > Jon: > I don't see what existing URI schemes can do this - if there is such a URI > scheme that fulfills the "MUST check ENUM or die" requirement, then please > holler and we can save some meeting time. > It has been suggested that a tel URL parameter would be sufficient for this purpose. There can be mandatory tel URL parameters (see the text about behavior of the 'm-' prefix in rfc2806bis). An 'm-enum=yes' parameter on a tel URL would do nicely, I think. That much said, I maintain that this idea seems to have little practical application. The text from me that you cite above was not intended to speak to this 'check ENUM' concept, but rather to the fact that the ENUM URI proposal satisfies requirements that are very much orthogonal to the ENUM problem. If you want a URI scheme for some kind of opaque pointer and that can be dereferenced to return a set of communications records, there are a number to choose from that are totally unrelated to ENUM (why not just use LDAP?). ENUM is a technology for translating telephone numbers into URIs - you need that when you have a telephone number that you don't know what to do with. If you know enough about a telephone number to be able to decide that it should be represented with an ENUM URI scheme rather than a tel URL scheme... then you are already well outside ENUM's problem space, and you might as well be using LDAP URIs instead. In what context do you imagine that that the ENUM URI would be used? What agent or machine will generate ENUM URIs, and for what purpose? The use of telephone numbers as a component of this opaque pointer is probably totally superfluous. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 14 17:59:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07389 for ; Thu, 14 Nov 2002 17:59:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEN1ic31960 for enum-archive@odin.ietf.org; Thu, 14 Nov 2002 18:01:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEN1cv31954; Thu, 14 Nov 2002 18:01:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEMwSv31845 for ; Thu, 14 Nov 2002 17:58:28 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05295 for ; Thu, 14 Nov 2002 17:55:46 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Nov 2002 22:58:20 -0000 Received: from babelfish.srmr.co.uk (percy.roke.co.uk [193.118.192.111]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W7Y8V535; Thu, 14 Nov 2002 22:58:16 -0000 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Thu, 14 Nov 2002 22:56:53 +0000 Subject: [Enum] RE: "enum:" URI comments Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Folks, Jon said: >I had thought this thread had relocated to iptel, but, a response inline. To which I reply: Sorry - didn't realise this - last posts on this were on this list so must have missed the ones on ipTEL. >Jon Peterson >NeuStar, Inc. > >> -----Original Message----- >> From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] >> Sent: Thursday, November 14, 2002 5:05 AM >> To: enum@ietf.org >> Cc: jon.peterson@neustar.biz; michael.michael@neonym.net >> Subject: "enum:" URI comments >> >> > > Hi John, Michael, Folks, Sorry for the misspelt name - didn't stop the spell checker on this one. > > A long time ago, in a land far away, Jon said: >> At 4:55 pm -0500 3/9/02, Peterson, Jon wrote: >> >The ENUM URI in this case would be an opaque pointer >> >to a set of communications records, but this requirement could be >fulfilled >> >by any number of existing URI schemes that have no bearing on telephone >> >numbers (I'm sure DDDS would allow this in any number of ways). >> >> Jon: >> I don't see what existing URI schemes can do this - if there is such a URI >> scheme that fulfills the "MUST check ENUM or die" requirement, then please >> holler and we can save some meeting time. >> > >It has been suggested that a tel URL parameter would be sufficient for this >purpose. There can be mandatory tel URL parameters (see the text about >behavior of the 'm-' prefix in rfc2806bis). An 'm-enum=yes' parameter on a >tel URL would do nicely, I think. That decides the destination for 2806bis - it has to obsolete 2806 to bring in MANDATORY behaviour as that was NOT in 2806, and that means it's Proposed as the required behaviour is radically different. RFCs aside, you can't change existing tel: clients by fiat (or for free :). >That much said, I maintain that this idea seems to have little practical >application. The text from me that you cite above was not intended to speak >to this 'check ENUM' concept, but rather to the fact that the ENUM URI >proposal satisfies requirements that are very much orthogonal to the ENUM >problem. If you want a URI scheme for some kind of opaque pointer and that >can be dereferenced to return a set of communications records, there are a >number to choose from that are totally unrelated to ENUM (why not just use >LDAP?). (more on "the ENUM problem next") So you suggest that I need an LDAP client to de-reference an opaque pointer? >ENUM is a technology for translating telephone numbers into URIs - >you need that when you have a telephone number that you don't know what to >do with. If you know enough about a telephone number to be able to decide >that it should be represented with an ENUM URI scheme rather than a tel URL >scheme... then you are already well outside ENUM's problem space, and you >might as well be using LDAP URIs instead. I agree that this is what the ENUM lookup is all about. As you put it, to "de-reference" a phone number to a set of communications records. If I, as a publisher of information (say, on a web page, or wherever), want to ensure that the READERS of that page check ENUM, how do I do it? The reader doesn't have enough information to know that they MUST check. The sender/publisher does. Yes, if I wanted to store the information inside an LDAP server instead of in the ENUM golden tree, and to force clients to retrieve it from LDAP rather than DNS, then I could use LDAP URIs. Are you seriously suggesting that we dump ENUM and go over to LDAP? >In what context do you imagine >that that the ENUM URI would be used? What agent or machine will generate >ENUM URIs, and for what purpose? The use of telephone numbers as a component >of this opaque pointer is probably totally superfluous. How will it be used? - on my web page (created using BBEdit on my TiBook and uploaded to the web server using FTP) for a start. Purpose? - to indicate where to go to find my contact info, WITHOUT requiring an LDAP client (and opening pinholes to support this protocol) on the receiving end. Using telephone numbers as a tag is superfluous if one is NOT using ENUM DNS lookups, I guess. They are the fundamental key to ENUM, hence they must be the value of any "check ENUM" URI, seems to me. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 14 19:12:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09566 for ; Thu, 14 Nov 2002 19:12:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAF0ECU03408 for enum-archive@odin.ietf.org; Thu, 14 Nov 2002 19:14:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF0EAv03402; Thu, 14 Nov 2002 19:14:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF0Afv03311 for ; Thu, 14 Nov 2002 19:10:41 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09463 for ; Thu, 14 Nov 2002 19:07:57 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Nov 2002 00:10:32 -0000 Received: from babelfish.srmr.co.uk (percy.roke.co.uk [193.118.192.111]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W7Y8V5PT; Fri, 15 Nov 2002 00:10:27 -0000 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Cc: Rich , Richard Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Fri, 15 Nov 2002 00:09:00 +0000 Subject: Re: [Enum] Regarding brandner-compendium discussion in ATL Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Folks, Our esteemed co-chair asks about the the compendium draft = [Rich sez:] Herewith my responses. [LWC sez:] (Comprised Services) Rich sez: why cant you just call dap ldap? LWC sez: because we WERE trying to use different names for the enumservice and protocol symbols as per earlier list discussions. Strictly, we shouldn't use sip and h232, as these are also protocol symbols. However, as the sip draft always mentions 'sip' as an enumservice, and the h323 draft always talks about 'h323' as an anumservice, we try to oblige. [IMHO, this is nasty, as it forces positional sub-field processing, but...] Rich sez: E2U+ldap:srs LWC sez: I think that this has swapped the enumservice sub-field and the protocol sub-field. "ldap:" is the the URI scheme we copy into the protocol sub-field, and srs is the enumservice. You may have done this elsewhere... It would break our client, as we've just thrown away the separate "protocol" and "enumservice" symbol list scanning code (to allow for sip and h323 to appear in both lists) - now it expects to find the enumservice sub-field as the first one of each block (as in rfc2916bis-01). I suspect it would break the Infonova client, and the AOSA client. I'm sure there are others who get rained on by this change. I guess that this wasn't intended just to pi** off the coders (amusing as this can be with Trial deadlines stressing them all :), so why is this swap NEEDED? Rich sez: You are not suggesting E2U+sip:srs are you ... or E2U+h323:srs ? why is this necessary? LWC sez: Strictly, we're suggesting E2U+srs or E2U+srs:sip or E2U+srs:h323, or E2U+sip or E2U+h323. According to rfc2916bis-01, the first sub-field is the enumservice, so these examples mean: enumservice = 'srs', protocol unspecified (evaluate URI to find out) enumservice = 'srs', protocol = SIP enumservice = 'srs', protocol = H.323 enumservice = 'sip', protocol unspecified (but you can guess :) enumservice = 'h323', protocol unspecified (but you may guess :) Thus, are we suggesting E2U+srs:sip? - yup, you *could* do this. You *could* also put E2U+all:sip. Either is a little overkill, though. (All is a catch-all category, so it matches everything or anything). SRS is a category, so that it's more likely to be specified by the (client) end user rather than being in a NAPTR service field. If the client has said they're interested in this kind of communication, then it will match with a supported enumservice of 'sip' or 'h323' (or 'srs') found in a retrieved NAPTR. I (and others) contend that we do not want to FORCE an ENUM registrant to have only one service provider for all of their SIP protocol uses. I understand that this is possible, but do not accept that it is a requirement. I have more than one sip AoR, so it is patently not NEEDED. In particular, I have one AoR for use with IM, plus two others that I use; for SIP/PSTN calls. Note what's missing here? - an SRS. These are specific for 'im' (messages) and for 'voice' (talking). Thus, 'sip' would appear as the protocol within a number of different NAPTRs - one for enumservice 'voice', one for enumservice 'im'. Now we have the 'sip and 'h323' enumservices, you could just use 'E2U+sip' or 'E2U+h323' in a single NAPTR and you're done for ENUM. I guess that it's valid for someone to have yet another sip AoR that acts as a general SRS - thus you could have one for you IM service provider (from Redmond, say), one for voice (from Clinton, say) and one that is an SRS - from your Universal Messaging Service provider. I can't see why anyone would have all of these, but I'm not going to stop them doing this. In short, if folk want to have separate services, they can. If folk want only a single E2U+SRS or E2U+sip or E2U+h323 entry, that's fine too. Seems reasonable to me, so I don't see the problem. ---- Rich sez: IMHO the general case is E2U+enumservice:enumdescription1:enumdescription2:etc where enumdescription is purely optional on the part of the ENUM registrant LWC sez: Right now, we have E2U+: Of these, the protocol part is optional. Now... Rich sez: E2U+voice:sip is not acceptable E2U+sip:voice where "voice" is purely optional is. LWC sez: Well....that's why I don't like using sip (or h323) as both a protocol AND as an enumservice. In the first example, (using I guess the above ordering of sub-fields) the enumsevice is 'voice' whilst the protocol or enumdescription1 is sip. Well....sip may well be the protocol, so using rfc2916bis-01 format, that's fine. However, if it's a description only (using your syntax), then there's no need for it so I'd agree that doesn't make sense. In the second example, it is NOT OK if using rfc2916bis-01 syntax, as there's no protocol called 'voice' (AFAICT). This is OK using your syntax as voice is a description. However, the enumservice 'sip' claims to be an SRS. Thus the extra information is strange - why hide all of your services behind an SRS and then tell people what kind of communication they can expect? Rich sez: I still do not understand the difference between "talk" and "voice" and "ivoice" - I do not understand the difference between "chat" and "im". LWC sez: OK - that can be improved in compendium-01. "talk" is a general kind of communication - as in a bidirectional interchange using continuous media exchange, whilst "voice" is a more specific kind of this category of communication. "ivoice" is a variant on voice - it's identical except that, *if the client has a choice on delivering their call*, this should be to an IP-based interconnect, whilst "voice" is, if anything, a PSTN end point so the call should be delivered to a PSTN interconnect, by preference. It's a very minor point but may allow some ENUM-like systems to avoid the spectacle of up to 6 transcodes between PSTN and IP worlds. 'chat' is a distinct kind of message exchange, in which the messages are exchanged in a session-oriented fashion. 'im' is similar, but each message is sent outside a session - as a "one-off". For example, text phones are a session oriented system, as they require a connection to be nailed up for the terminals to exchange data. SMS, on the other hand, is a pure message based system - no session is made between the correspondents. Rich sez: E2U+tel:fax makes sense, a PSTN fax call .. E2U+tel:textphone seems very useful. LWC sez: except that we do not have a 'tel' enumservice. Now, I seem to recall that folk did not like this at all when we proposed it originally. 'tel' is a pseudo-protocol, it's not an enumservice as they are defined right now. The compendium lists the kind of enumservices that one would expect to see in a NAPTR alongside a "tel:" URI. One of these is 'fax' - it's a kind of 'msg' service. When I send a fax, that's the teleservice/feature I'm using, not just the phone line. So, from a caller's perspective, knowing that this contact is for fax is pretty important. Thus (in rfc2916bis-01 format) "E2U+fax:tel" is fine - fax is the enumservice, whilst this is executed using the "tel:" URI. Rich sez: E2U+tel:mobile:sms makes sense .. LWC sez: Well, put this as E2U+sms:tel:mobile and I might agree. The mobile (or home, or office, or any of the other VCARD-style qualifiers) is sure something to consider - I'm still not convinced that we need a "protocol" sub-field as the client can "look to the right" in the NAPTR, as Richard puts it. Thus we could lose the ":tel" bit in the middle, IMHO. Having these kind of "real" qualifiers seems like a good (but optional) use of bytes - at least it's not duplicating stuff. This is going to need some spec to ensure that the Client and publisher/Registrant both use a common set of values. Do you think that the VCARD definitions are a start, or do folks prefer some different spec for these kind of qualifiers? all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 14 22:45:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16890 for ; Thu, 14 Nov 2002 22:45:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAF3lWN16660 for enum-archive@odin.ietf.org; Thu, 14 Nov 2002 22:47:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF3lTv16655; Thu, 14 Nov 2002 22:47:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF3ipv16585 for ; Thu, 14 Nov 2002 22:44:51 -0500 Received: from tisch.mail.mindspring.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16841 for ; Thu, 14 Nov 2002 22:42:07 -0500 (EST) Received: from user-uiveq2g.dsl.mindspring.com ([165.247.104.80] helo=dick.ix.netcom.com) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18CXPA-0007cF-00; Thu, 14 Nov 2002 22:44:29 -0500 Message-Id: <5.2.0.9.2.20021114220149.03cf9e70@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 14 Nov 2002 22:45:14 -0500 To: "Conroy, Lawrence (SMTP)" , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] Regarding brandner-compendium discussion in ATL Cc: Rich , Richard In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 07:09 PM 11/14/2002 -0500, Conroy, Lawrence (SMTP) wrote: >Hi Folks, > Our esteemed co-chair asks about the the compendium draft = [Rich sez:] >Herewith my responses. [LWC sez:] > > >(Comprised Services) >Rich sez: why cant you just call dap ldap? >LWC sez: because we WERE trying to use different names for the enumservice >and protocol symbols as per earlier list discussions. >Strictly, we shouldn't use sip and h232, as these are also protocol symbols. >However, as the sip draft always mentions 'sip' as an enumservice, and >the h323 draft always talks about 'h323' as an anumservice, we try to >oblige. >[IMHO, this is nasty, as it forces positional sub-field processing, but...] huh? do not grok last sentence.. >Rich sez: E2U+ldap:srs >LWC sez: I think that this has swapped the enumservice sub-field and the >protocol sub-field. "ldap:" is the the URI scheme we copy into the protocol >sub-field, and srs is the enumservice. You may have done this elsewhere.. In my humble view ldap is the service and srs is the description of the service..that was my point. >It would break our client, as we've just thrown away the separate "protocol" >and "enumservice" symbol list scanning code (to allow for sip and h323 to >appear in both lists) - now it expects to find the enumservice sub-field >as the first one of each block (as in rfc2916bis-01). >I suspect it would break the Infonova client, and the AOSA client. I'm >sure there are others who get rained on by this change. >I guess that this wasn't intended just to pi** off the coders (amusing as >this can be with Trial deadlines stressing them all :), so why is this >swap NEEDED? the behavior of your client is of no concern to the WG this needs to be worked out Monday .. I'm personally not in favor of this approach and will argue this position vigorously. >Rich sez: You are not suggesting E2U+sip:srs are you ... or E2U+h323:srs ? >why is this necessary? > >LWC sez: Strictly, we're suggesting E2U+srs or E2U+srs:sip or E2U+srs:h323, >or E2U+sip or E2U+h323. >According to rfc2916bis-01, the first sub-field is the enumservice, so these >examples mean: >enumservice = 'srs', protocol unspecified (evaluate URI to find out) >enumservice = 'srs', protocol = SIP >enumservice = 'srs', protocol = H.323 >enumservice = 'sip', protocol unspecified (but you can guess :) >enumservice = 'h323', protocol unspecified (but you may guess :) I will oppose this. SIP is the service... IMHO it needs no additional embellishment. a description possibly.. >Thus, are we suggesting E2U+srs:sip? - yup, you *could* do this. NO .. >You *could* also put E2U+all:sip. Either is a little overkill, though. >(All is a catch-all category, so it matches everything or anything). ABSOLUTELY NO WAY I believe the SIP community would strongly oppose such an approach. >SRS is a category, so that it's more likely to be specified by the >(client) end user rather than being in a NAPTR service field. If the client >has said they're interested in this kind of communication, then it will >match with a supported enumservice of 'sip' or 'h323' (or 'srs') found >in a retrieved NAPTR. you are not accommodating the requirements of the called party here.. I want to make it abundantly clear my position... it is the called party that is in control here of the entire process..what the calling party wants is frankly irrlevant. It is the called party that must register their preferences in the global DNS and how they choose to expose data is IMHO the primary consideration. If registrants do not participate in the global ENUM system and trust it to protect their privacy when required this is a futile excersise. >I (and others) contend that we do not want to FORCE an ENUM registrant >to have only one service provider for all of their SIP protocol uses. >I understand that this is possible, but do not accept that it is a >requirement. I have more than one sip AoR, so it is patently not NEEDED. How does the construct prohibit more than one SIP service provider that is what order and preference fields are for. >In particular, I have one AoR for use with IM, plus two others that I use; >for SIP/PSTN calls. Note what's missing here? - an SRS. >These are specific for 'im' (messages) and for 'voice' (talking). fine contact the sip proxy of the called party identified and they will tell you what where and how to complete the session >Thus, 'sip' would appear as the protocol within a number of different >NAPTRs - one for enumservice 'voice', one for enumservice 'im'. so what the problem .. >Now we have the 'sip and 'h323' enumservices, you could just use >'E2U+sip' or 'E2U+h323' in a single NAPTR and you're done for ENUM. my point >I guess that it's valid for someone to have yet another sip AoR >that acts as a general SRS - thus you could have one for you IM >service provider (from Redmond, say), one for voice (from Clinton, say) >and one that is an SRS - from your Universal Messaging Service provider. > >I can't see why anyone would have all of these, but I'm not going to >stop them doing this. > >In short, if folk want to have separate services, they can. >If folk want only a single E2U+SRS or E2U+sip or E2U+h323 entry, >that's fine too. >Seems reasonable to me, so I don't see the problem. good ... but a totally separate SRS outside the scope of sip and h323 , which has not been defined _at this time_ is out side the scope of your draft. >---- > >Rich sez: IMHO the general case is >E2U+enumservice:enumdescription1:enumdescription2:etc >where enumdescription is purely optional on the part of the ENUM registrant > >LWC sez: Right now, we have E2U+: >Of these, the protocol part is optional. well the service may represent a protocol but I'm willing to admit hints to the capability of the end points to permit calling parties a choice of endpoints. You continue to avoid my points here. >Now... >Rich sez: E2U+voice:sip is not acceptable > E2U+sip:voice where "voice" is purely optional is. >LWC sez: Well....that's why I don't like using sip (or h323) as both >a protocol AND as an enumservice. we have differing opinions of this. >In the first example, (using I guess the above ordering of sub-fields) >the enumsevice is 'voice' whilst the protocol or enumdescription1 is >sip. Well....sip may well be the protocol, so using rfc2916bis-01 format, >that's fine. However, if it's a description only (using your syntax), then >there's no need for it so I'd agree that doesn't make sense. This is the issue .. in the draft the relationship between service needed and enumservice aka protocol is not clear. I hppe to see clarification and direction of where Patrik and Michael are going at this point. >In the second example, it is NOT OK if using rfc2916bis-01 syntax, as >there's no protocol called 'voice' (AFAICT). >This is OK using your syntax as voice is a description. However, the >enumservice 'sip' claims to be an SRS. Thus the extra information is >strange - why hide all of your services behind an SRS and then tell >people what kind of communication they can expect? some SIP endpoints may not be capable of IM for instance I may have one provider for SIP IM and another for SIP voice.. >Rich sez: I still do not understand the difference between "talk" and >"voice" and "ivoice" - I do not understand the difference between "chat" >and "im". > >LWC sez: OK - that can be improved in compendium-01. >"talk" is a general kind of communication - as in a bidirectional >interchange using continuous media exchange, whilst "voice" is a more >specific kind of this category of communication. "ivoice" is a >variant on voice - it's identical except that, *if the client has a >choice on delivering their call*, this should be to an IP-based >interconnect, whilst "voice" is, if anything, a PSTN end point so >the call should be delivered to a PSTN interconnect, by preference. >It's a very minor point but may allow some ENUM-like systems to avoid >the spectacle of up to 6 transcodes between PSTN and IP worlds. again this is really really messy IMHO >'chat' is a distinct kind of message exchange, in which the messages >are exchanged in a session-oriented fashion. 'im' is similar, but each >message is sent outside a session - as a "one-off". >For example, text phones are a session oriented system, as they require >a connection to be nailed up for the terminals to exchange data. SMS, >on the other hand, is a pure message based system - no session is made >between the correspondents. > >Rich sez: E2U+tel:fax makes sense, a PSTN fax call .. >E2U+tel:textphone seems very useful. > >LWC sez: except that we do not have a 'tel' enumservice. Now, I seem to >recall that folk did not like this at all when we proposed it originally. point well taken .. I was thinking that if someone wanted to send me a fax and the only methodology I permitted was PSTN G3 then the construct made sense in the context of called party control...but realistically this could be done through SIP as well >One of these is 'fax' - it's a kind of 'msg' service. When I send a fax, >that's the teleservice/feature I'm using, not just the phone line. >So, from a caller's perspective, knowing that this contact is for fax is >pretty important. Thus (in rfc2916bis-01 format) "E2U+fax:tel" is fine - >fax is the enumservice, whilst this is executed using the "tel:" URI. > >Rich sez: E2U+tel:mobile:sms makes sense .. >LWC sez: Well, put this as E2U+sms:tel:mobile and I might agree. agggg.. tel is the service sms is the capability or application of the endpoint. >The mobile (or home, or office, or any of the other VCARD-style qualifiers) >is sure something to consider - I'm still not convinced that we need a >"protocol" sub-field as the client can "look to the right" in the NAPTR, >as Richard puts it. Thus we could lose the ":tel" bit in the middle, IMHO. >Having these kind of "real" qualifiers seems like a good (but optional) >use of bytes - at least it's not duplicating stuff. > >This is going to need some spec to ensure that the Client and >publisher/Registrant >both use a common set of values. exactly >Do you think that the VCARD definitions are a start, or do folks prefer >some different spec for these kind of qualifiers? pointer to white page like info ..sure .. but its a option to the registrant only some folks may want that there others ..probably most do not but then you can get white page like data from Google if you have to... the issue is called party (aka registrant) control of what goes into the DNS. I've actually thought of geospatial data enumservice might be useful for mapping etc. E2U+http:map to a http site with GML object... local restaurants might find it helpful. >all the best, > Lawrence >-- >----------------------------------------------------------------------- >Roke Manor Research : This information is provided "as is" and is not >: intended to create any contractual or legal > : relationship. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Nov 15 06:15:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05151 for ; Fri, 15 Nov 2002 06:15:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFBI3l16638 for enum-archive@odin.ietf.org; Fri, 15 Nov 2002 06:18:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFBHxv16628; Fri, 15 Nov 2002 06:17:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFBG6v16579 for ; Fri, 15 Nov 2002 06:16:06 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05114 for ; Fri, 15 Nov 2002 06:13:27 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Enum] Regarding brandner-compendium discussion in ATL MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Nov 2002 12:19:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620248A6@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Regarding brandner-compendium discussion in ATL Thread-Index: AcKMCl3HVDM7v/r0Rsqfl2W39EDyZwAeDM6w From: "Stastny Richard" To: "Richard Shockey" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAFBG6v16580 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit He, he, Rich I think this discussion is a bit getting out of hand: service, enumservice, protocol, URI, ... Now I am totally confused. Rich says: >IMHO >the general case is >E2U+enumservice:enumdescription1:enumdescription2:etc where >enumdescription is purely optional on the part of the ENUM registrant >E2U+voice:sip is not acceptable >E2U+sip:voice where "voice" is purely optional is. So you do not accept the current version of 2916bis-01 which says: -begin- 2.4.2 Services Parameters Service Parameters for this Application take the following form and are found in the Service field of the NAPTR record. service_field = "E2U" 1*(enumservice) enumservice = service [":" protocol] service = 1*32(ALPHA / DIGIT) protocol = 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 1 or more or more Enumservices which indicate what class of functionality a given end point offers. Each Enumservice is indicated by an initial '+' character. The empty string is also valid. This will typically be seen at the beginning of a series of Rules, when it is impossible to know what services and protocols will be offered at the end of a particular delegation path. 2.4.2.1 ENUM Services An enumservice MUST be registered with the IANA via a description in an RFC. Enumservices specifications contain the functional specification (i.e. what it can be used for), the valid protocols, and the URI schemes that may be returned. Note that there is no implicit mapping between the textual string "protocol" and "service" in the grammar for the Enumserver and URI schemes. The mapping have to be made explicit in the specification for the Enumservice itself. It is allowed to specify the service and protocol in two different documents, to make the description coherent and easy to understand. For example, the Enumservice "presence" (note, no protocol specification) would define the various URI schemes ("im:", "mailto:") can be used and what the service can be used for ("Where is the owner of this E.164 number?"). Another example might be "talk:sip" which can specify that the URI must use the 'sip:' URI scheme and use the SIP protocol to make a voice call (as opposed to a voice mail call or fax call). What final protocol to use for the actual transport of voice is negotiated in the SIP protocol negotiation. -end- so talk:sip IS ACCEPTABLE - period (and so is voice:sip, which is nearly the same) We have made for our trial four basic decisions: 1. it is based on RFC2916bis 2. we go for the calling party controls approach (see your own draft on privacy) including the called party approach automatically 3. We used the brandner-compendium for enumservices (selection), because it is the only one available 4. We do not use at the moment the optional ":protocol" field, because we look at the "right" To this some comments: on 2: We see both calling and called party control approach to be requested by the user, it is their decision. The called party control is a subset and included automatically, but currently there is NO full srs:sip or srs:h323 available to offer to trial users (we are still struggling to offer them voice:sip and voice:h323, but we do;-). Additionally, there will always be new enumservices possible in addition to sip, so we see for a long time a combination of the two approaches e.g. srs:sip and key:ldap or location:foo And finally, as I have told you already, we want to find out what the ENUM users and ENUM subscribers really prefer, so we offer both options. on 3: as I have stated in a previous mail, we have no problem to incorporate the two drafts on sip and h323. on 4. Currently we are using e.g. "E2U+voice" or "E2U+sms" or "E2U+srs" and it works but we can easily also use "E2U+voice:sip", "E2U+sms:tel", "E2U+srs:sip", if required. Or lets say, it does not hurt, because it is optional;-) We also may easily understand "E2U+sip", which is equivalent to "E2U+srs" with sip: URI BTW, where did you get >E2U+tel:mobile:sms makes sense .. from? We use E2U+sms with a tel: URI which may be fixed or mobile. The idea in an earlier draft with home, mobile etc was, that if a user wants to point to different voice options to give hints to the caller (in the calling party controls scenario). But we do not use this at the moment. Rich says: >you are not accommodating the requirements of the called party here.. I >want to make it abundantly clear my position... it is the called party that >is in control here of the entire process..what the calling party wants is >frankly irrlevant. It is the called party that must register their >preferences in the global DNS and how they choose to expose data is IMHO >the primary consideration. This is only one possibility. Again: read your own draft on privacy;-) Now we are coming to the serious stuff: Lawrence: >This is going to need some spec to ensure that the Client and >publisher/Registrant both use a common set of values. Rich: exactly Rich again: the behavior of your client is of no concern to the WG What is the concern of the WG? I always thought the concern of the IETF and therefor also for the ENUM WG is standardization for interoperability. The statement from Lawrence comes out from the key point of the current work going on in ETSI on "Minimum requirements for interoprability of the European ENUM Trials". And the key point is: If I set up a trial in UK with ENUM subscribers entering their data in an UK Tier 2 and also provide ENUM users in UK with clients, this will work, because the enumservices and URI to be used with this enumservices are defined within the trial. I did the same in Austria. Now a ENUM user in Austria wants to query the UK tier 2 or vice versa. Since NOTHING is defined yet by ENUM WG, and we cannot just reference some RFCs, the chances are high that the definitions in UK do not match the definitions in Austria, or Sweden, or Netherland or Switzerland, except they talk to each other beforehand. This is exactly whats going on in ETSI, and the only reference we currently have is the RFC2916bis and the brandner-compendium, and we want to have a quite stable draft to work on in Dezember and finalize it in January. Sorry, but EU is not US and we still have diffenent countries (and we have trials). Now I come to the fun stuff: I have to admit beforehand that although I am around now for years in this business, I still have no sufficent definition found for service. The result in YOK regarding this issue was foo, eventually with bar. From RFC2916bis again: Note that there is no implicit mapping between the textual string "protocol" and "service" in the grammar for the Enumserver (should read emumservice) and URI schemes. But Rich seems to know (This is what I grabbed from your last e-mail): -begin Rich on services, protocols, etc.- In my humble view ldap is the service and srs is the description of the service..that was my point. I will oppose this. SIP is the service... IMHO it needs no additional embellishment. a description possibly.. well the service may represent a protocol but I'm willing to admit hints to the capability of the end points to permit calling parties a choice of endpoints. You continue to avoid my points here. point well taken .. I was thinking that if someone wanted to send me a fax and the only methodology I permitted was PSTN G3 then the construct made sense in the context of called party control...but realistically this could be done through SIP as well tel is the service sms is the capability or application of the endpoint. -end Rich- The last one is the best, this throws me off completely: tel is now a service and we have two new terms: capability and application. I really waited for this to to come up. We had this fun already in TIPHON: If you try to defines service, you finally run into a dead end, turn tree times around and emerge with terms like capability, service capability, application, application service, service application, application service capability, category, service categories, features, supplementary services (hoppla, thats an old one). And this is the end of dicussion, because everybody is totally confused and does not know what others are taking about. So we are now talking about enumservices, services, categories, protocols, URIs, capabilities and applications. Nice, do we still know what we are talking about? Ok Rich, I have to admit that you also finally recognized that there is a problem: Rich says: >This is the issue .. in the draft the relationship between service needed >and enumservice aka protocol is not clear. I hope to see clarification and >direction of where Patrik and Michael are going at this point. Good luck;-) May I help: What we have is RFC2916bis, the brandner-compendium and the sip and h323 drafts. RFC2916bis uses the terms enumservices and protocol, but state clearly, that they do not mean anything in itself, but the meaning needs to be defined in a specification, and the "protocol" part is optional. The brandner-compendium is doing exactly this for a bunch of enumservices, it defines what the enumservices are for and which URI (and real protocols) may be used. The compendium also groups the enumservices that have something in common into groups, giving these groups also a name and a definition to be used as enumservice (e.g. msg for all type of non-session related communication). The compendium also allows the URI used in the regexp to be mapped to the "protocol" as an option, although the URI may not be a real protocol. To prevent confusion between the enumservices and protocol names, we tried to use different names, and since the names to be used in the protocol part are predefined by the URIs, we had to chose other names for the enumservices (which was not so easy and led to some counterintuitve solutions (like dap). This even works for sip and h323 if used as "Service Resolution Services" in the form NAPTR "E2U+srs" .. sip:user@provider.net, but since we did not use sip and h323 as enumservices sofar, we can live with srs as category and sip, h323 as subcategory also. So we may have in parallel: "E2U+voice" with either sip: h323: or tel: for voice only (note that tel: may use either a sip or h323 client to establish the call) (and also note that "E2U+voice:sip", "E2U+voice:h323" and "E2U+voice:tel" are also possible) and "E2U+srs" .. with either sip: or h323: and "E2U+srs:sip" or "E2U+sip" , which are equivalent. So IMHO the brandner-compendium is a very generic approach for all types of usages in ENUM (it will also work for infrstructure ENUM) and also open for additional services, as has been seen with sip and h323 and I am sure this will also work with vpim and fax. One last word: we should not try to define the enumservices for what we (personally) think ENUM shall be used for, but should allow all thinkable usages. We should only try to enable this usages in a compatible way and let the implementors of services (aaagrh), subscribers and users decide. One example: If a ENUM subsciber decides to put a pointer to his name and address in ENUM, he should be able to do this (yes, I know, we have to let him fill out several form where he is declaring that he exactly knows what he he doing and that there is the possibility that Bin-Laden may scan the DNS and sent him an airplane ..) On the other hand, 95% of our phone customes are in the phone book with their name and address. And companies in general have no problem to put their names, addresses and geolocs and whatever in public (and if, the address is on cayman island anyway). If you are trying to prevent this beforehand, you are worse than some of the regulators and the privacy gurus, who all think everybody is completely nuts anyway and they are not and therefor they are the ones who have to do the thinking for the nuts. BTW, two days ago I saw a demo of an ENUM application, where the phone number in ENUM was put in a bar code, put on a business card (or a letter) and was read with a bar code reader connected to a Laptop, which triggered an ENUM query. And also BTW, postal services have already shown intest in GLOBALLY unique numbers for people or entities, if you know what I mean. I think we still cannot imagine all the applications possible with ENUM and I want to be open on all sides Best regards Richard (Stastny) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Nov 15 14:39:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16501 for ; Fri, 15 Nov 2002 14:36:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFJcYQ10521 for enum-archive@odin.ietf.org; Fri, 15 Nov 2002 14:38:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFJZdv09792; Fri, 15 Nov 2002 14:35:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFJPnv09323 for ; Fri, 15 Nov 2002 14:25:49 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16155 for ; Fri, 15 Nov 2002 14:23:07 -0500 (EST) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gAFJPfb25085; Fri, 15 Nov 2002 19:25:41 GMT Message-Id: <5.2.0.9.2.20021115135326.0442e020@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 15 Nov 2002 14:03:43 -0500 To: Stastny Richard , Richard Shockey , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] Regarding brandner-compendium discussion in ATL In-Reply-To: <06CF906FE3998C4E944213062009F1620248A6@oefeg-s02.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 06:19 AM 11/15/2002 -0500, Stastny Richard wrote: >He, he, Rich >I think this discussion is a bit getting out of hand: > >service, enumservice, protocol, URI, ... >Now I am totally confused. You too? :-) >Rich says: > > >IMHO > > >the general case is > > >E2U+enumservice:enumdescription1:enumdescription2:etc where > >enumdescription is purely optional on the part of the ENUM registrant > > >E2U+voice:sip is not acceptable > > >E2U+sip:voice where "voice" is purely optional is. > >So you do not accept the current version of 2916bis-01 >which says: > >-begin- > >2.4.2 Services Parameters > > Service Parameters for this Application take the following form and > are found in the Service field of the NAPTR record. > > > service_field = "E2U" 1*(enumservice) > enumservice = service [":" protocol] > service = 1*32(ALPHA / DIGIT) > protocol = 1*32(ALPHA / DIGIT) Yes ... I understand what you are getting at ..and Yes I think this definition needs to be refined so there is no ambiguity in what is permissible ... what is a required field and what is a protocol field. I think it would be terrible to have E2U+voice:sip and E2U+sip and or E2U+sip:voice I just think it would be way too difficult for applications to parse correctly >so talk:sip IS ACCEPTABLE - period (and so is voice:sip, which is nearly >the same) and confusing under the current definition but we have a draft that says E2U+sip is also acceptable and there are lots of folks who want this and nothing else. >We have made for our trial four basic decisions: > >1. it is based on RFC2916bis a work in progress remember..... >2. we go for the calling party controls approach (see your own draft >on privacy) including the called party approach automatically how do you define this? could you please elaborate .. >3. We used the brandner-compendium for enumservices (selection), because >it is the only one available >4. We do not use at the moment the optional ":protocol" field, because >we look at the "right" ok ... >To this some comments: >on 2: We see both calling and called party control approach to be >requested >by the user, it is their decision. The called party control is a subset >and >included automatically, but currently there is NO full srs:sip or >srs:h323 ok >available to offer to trial users (we are still struggling to offer them >voice:sip and voice:h323, but we do;-). Additionally, there will always >be new enumservices >possible in addition to sip, so we see for a long time a combination of >the two approaches e.g. srs:sip and key:ldap or location:foo >And finally, as I have told you already, we want to find out what the >ENUM users and ENUM subscribers really prefer, so we offer both options. of course ... >on 3: as I have stated in a previous mail, we have no problem to >incorporate >the two drafts on sip and h323. I'm wondering how you plan on harmonizing them...you want to incorporate the directly into your draft ..? You then object to having them move forward individually> >on 4. Currently we are using e.g. "E2U+voice" or "E2U+sms" or "E2U+srs" >and it works >but we can easily also use "E2U+voice:sip", "E2U+sms:tel", >"E2U+srs:sip", if required. >Or lets say, it does not hurt, because it is optional;-) >We also may easily understand "E2U+sip", which is equivalent to >"E2U+srs" with sip: URI > > >BTW, where did you get > > >E2U+tel:mobile:sms makes sense .. > >from? > >We use E2U+sms with a tel: URI which may be fixed or mobile. > >The idea in an earlier draft with home, mobile etc was, that if >a user wants to point to different voice options to give hints >to the caller (in the calling party controls scenario). But we >do not use this at the moment. > >Rich says: > >you are not accommodating the requirements of the called party here.. I > > >want to make it abundantly clear my position... it is the called party >that > >is in control here of the entire process..what the calling party wants >is > >frankly irrlevant. It is the called party that must register their > >preferences in the global DNS and how they choose to expose data is >IMHO > >the primary consideration. > >This is only one possibility. Again: read your own draft on privacy;-) > >Now we are coming to the serious stuff: > >Lawrence: > >This is going to need some spec to ensure that the Client and > >publisher/Registrant both use a common set of values. > >Rich: exactly > >Rich again: the behavior of your client is of no concern to the WG > >What is the concern of the WG? > >I always thought the concern of the IETF and therefor also for the ENUM >WG >is standardization for interoperability. > >The statement from Lawrence comes out from the key point of the current >work going on in ETSI on "Minimum requirements for interoprability >of the European ENUM Trials". And the key point is: If I set up a trial >in UK with ENUM subscribers entering their data in an UK Tier 2 and also > >provide ENUM users in UK with clients, this will work, because the >enumservices >and URI to be used with this enumservices are defined within the trial. >I did the same in Austria. Now a ENUM user in Austria wants to query the > >UK tier 2 or vice versa. > >Since NOTHING is defined yet by ENUM WG, and we cannot just reference >some RFCs, the chances are high that the >definitions in UK do not match the definitions in Austria, or Sweden, or >Netherland or Switzerland, except they talk to each other beforehand. >This is exactly whats going on in ETSI, and the only reference we >currently >have is the RFC2916bis and the brandner-compendium, and we want to have >a quite stable draft to work on in Dezember and finalize it in January. > >Sorry, but EU is not US and we still have diffenent countries (and >we have trials). > >Now I come to the fun stuff: > >I have to admit beforehand that although I am around now for years >in this business, I still have no sufficent definition found for >service. > >The result in YOK regarding this issue was foo, eventually with bar. > > From RFC2916bis again: >Note that there is no >implicit mapping between the textual string "protocol" and "service" >in the grammar for the Enumserver (should read emumservice) and URI >schemes. > >But Rich seems to know (This is what I grabbed from your last e-mail): > >-begin Rich on services, protocols, etc.- > >In my humble view ldap is the service and srs is the description of the >service..that was my point. > >I will oppose this. SIP is the service... IMHO it needs no additional >embellishment. a description possibly.. > >well the service may represent a protocol but I'm willing to admit hints >to >the capability of the end points to permit calling parties a choice of >endpoints. You continue to avoid my points here. > >point well taken .. I was thinking that if someone wanted to send me a >fax >and the only methodology I permitted was PSTN G3 then the construct made > >sense in the context of called party control...but realistically this >could >be done through SIP as well > >tel is the service sms is the capability or application of the >endpoint. >-end Rich- > >The last one is the best, this throws me off completely: >tel is now a service and we have two new terms: capability and >application. > >I really waited for this to to come up. We had this fun already in >TIPHON: >If you try to defines service, you finally run into a dead end, turn >tree >times around and emerge with terms like capability, service capability, >application, >application service, service application, application service >capability, category, >service categories, features, supplementary services (hoppla, thats an >old one). >And this is the end of dicussion, because everybody is totally >confused and does not know what others are taking about. > >So we are now talking about enumservices, services, categories, >protocols, URIs, >capabilities and applications. Nice, do we still know what we are >talking about? > >Ok Rich, I have to admit that you also finally recognized that there is >a problem: > >Rich says: > >This is the issue .. in the draft the relationship between service >needed > >and enumservice aka protocol is not clear. I hope to see clarification >and > >direction of where Patrik and Michael are going at this point. > >Good luck;-) > >May I help: > >What we have is RFC2916bis, the brandner-compendium and the sip and h323 >drafts. > >RFC2916bis uses the terms enumservices and protocol, >but state clearly, that they do not mean anything in itself, but the >meaning needs >to be defined in a specification, and the "protocol" part is optional. > >The brandner-compendium is doing exactly this for a bunch of >enumservices, >it defines what the enumservices are for and which URI (and real >protocols) >may be used. The compendium also groups the enumservices that have >something >in common into groups, giving these groups also a name and a definition >to be used >as enumservice (e.g. msg for all type of non-session related >communication). > >The compendium also allows the URI used in the regexp to be mapped to >the "protocol" as an option, although the URI may not be a real >protocol. > >To prevent confusion between the enumservices and protocol names, we >tried >to use different names, and since the names to be used in the protocol >part >are predefined by the URIs, we had to chose other names for the >enumservices >(which was not so easy and led to some counterintuitve solutions (like >dap). > >This even works for sip and h323 if used as "Service Resolution >Services" >in the form NAPTR "E2U+srs" .. sip:user@provider.net, but since we did >not use sip and >h323 as enumservices sofar, we can live with srs as category and sip, >h323 as subcategory >also. > >So we may have in parallel: > >"E2U+voice" with either sip: h323: or tel: for voice only >(note that tel: may use either a sip or h323 client to establish the >call) >(and also note that "E2U+voice:sip", "E2U+voice:h323" and >"E2U+voice:tel" are >also possible) > >and >"E2U+srs" .. with either sip: or h323: >and >"E2U+srs:sip" or "E2U+sip" , which are equivalent. > >So IMHO the brandner-compendium is a very generic approach for all types >of usages in ENUM (it will also work for infrstructure ENUM) and also >open for additional services, as has been seen with sip and h323 and >I am sure this will also work with vpim and fax. > >One last word: we should not try to define the enumservices >for what we (personally) think ENUM shall be used for, >but should allow all thinkable usages. > >We should only try to enable this usages in a compatible way >and let the implementors of services (aaagrh), subscribers and >users decide. > >One example: >If a ENUM subsciber decides to put a pointer >to his name and address in ENUM, he should be able >to do this (yes, I know, we have to let him fill out >several form where he is declaring that he exactly knows >what he he doing and that there is the possibility that >Bin-Laden may scan the DNS and sent him an airplane ..) > >On the other hand, 95% of our phone customes are in the >phone book with their name and address. And companies in >general have no problem to put their names, addresses and >geolocs and whatever in public (and if, the address is on cayman >island anyway). > >If you are trying to prevent this beforehand, you are worse >than some of the regulators and the privacy gurus, who all >think everybody is completely nuts anyway and they are not and therefor >they are the ones who have to do the thinking for the nuts. > >BTW, two days ago I saw a demo of an ENUM application, where >the phone number in ENUM was put in a bar code, put on a business card >(or a letter) and was read with a bar code reader connected to a Laptop, >which triggered an ENUM query. > >And also BTW, postal services have already shown >intest in GLOBALLY unique numbers for people or entities, if you know >what I mean. > >I think we still cannot imagine all the applications possible >with ENUM and I want to be open on all sides > >Best regards >Richard (Stastny) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Nov 15 16:40:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20249 for ; Fri, 15 Nov 2002 16:38:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFLePL18993 for enum-archive@odin.ietf.org; Fri, 15 Nov 2002 16:40:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFLbcv18619; Fri, 15 Nov 2002 16:37:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFL81v16696 for ; Fri, 15 Nov 2002 16:08:01 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19085 for ; Fri, 15 Nov 2002 16:05:19 -0500 (EST) content-class: urn:content-classes:message Subject: AW: [Enum] Regarding brandner-compendium discussion in ATL MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Fri, 15 Nov 2002 22:10:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620248AC@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Regarding brandner-compendium discussion in ATL Thread-Index: AcKM3TbEsXgv1RKqTEKfYOXNyeO+EgAC6F14 From: "Stastny Richard" To: "Richard Shockey" , "Richard Shockey" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gAFL9Mv16733 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Rich Shockey : >>on 3: as I have stated in a previous mail, we have no problem to >>incorporate >>the two drafts on sip and h323. >I'm wondering how you plan on harmonizing them...you want to incorporate >them directly into your draft ..? >You then object to having them move forward individually No , (I am speaking now as co-author without consulting), I personally consider the draft partially as framework and already complicated enough. For srs (sip, h323) we do not much elaborate and leave the details to the experts. The enumservices srs and h323 just plug in, and they should move forward individually. So it is definitely not an question of compendium or sip (h323), its both. Maybe this can be stated in a new version more clearly, when we just can put in a reference. The same should be the case with section 15. im (instant messaging). This should be done by the specialists. A lot of work will also be required with ldap. Additional enumservices may be added later to this framework, e.g. the public key and location services (capabilities?) we already discussed., eventually also in separate documents. regards Richard Stastny _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Nov 15 17:09:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21315 for ; Fri, 15 Nov 2002 17:09:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFMC5c21428 for enum-archive@odin.ietf.org; Fri, 15 Nov 2002 17:12:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFMC2v21420; Fri, 15 Nov 2002 17:12:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFM6Yv20643 for ; Fri, 15 Nov 2002 17:06:34 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21198 for ; Fri, 15 Nov 2002 17:03:53 -0500 (EST) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gAFM6Sb28818 for ; Fri, 15 Nov 2002 22:06:28 GMT Message-Id: <5.2.0.9.2.20021115170624.022c4830@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 15 Nov 2002 17:07:23 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Is anyone interested in volunteering as a scribe for the meeting... Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , please ...it will help speed things along on monday. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Nov 18 01:02:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03800 for ; Mon, 18 Nov 2002 01:02:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAI64Z826706 for enum-archive@odin.ietf.org; Mon, 18 Nov 2002 01:04:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAI64Iv26697; Mon, 18 Nov 2002 01:04:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAI5xdv26579 for ; Mon, 18 Nov 2002 00:59:39 -0500 Received: from mail.cdt.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03636 for ; Mon, 18 Nov 2002 00:56:52 -0500 (EST) Received: from tosh (cdt [206.112.85.61]) by mail.cdt.org (Postfix) with ESMTP id B092B4900AA for ; Mon, 18 Nov 2002 00:31:59 -0500 (EST) Message-Id: <4.2.0.58.20021117233530.009ba190@localhost> X-Sender: john@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 18 Nov 2002 00:57:06 -0500 To: enum@ietf.org From: John Morris Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Last minute comments on draft-shockey-enum-privacy-security-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Rich, all, Let me offer a few last minute reactions to the enum-privacy-security draft. I unfortunately have a conflict with the Monday WG meeting and so cannot offer these in person. Although until now I've not actively participated in discussions on this list, I've been looking at privacy issues surrounding ENUM for some time. I'd be interested in contributing to further work on this draft. Broadly speaking, there are two distinct areas where privacy concerns could be implicated by ENUM. First is the question of what potentially private information must be exposed in the context of an ENUM transaction itself (a lookup in the DNS as part of, possibly, the initiation of a voice or other communication). Second is the question of what info is required (by a national ENUM authority) to authorize the insertion of an E.164/ENUM record into the DNS. Let me comment on these two areas separately. With the first area, the breakout of three conceptions of ENUM offered in the internet-draft is, I think, very constructive for thinking about privacy. Looking at the "second view" of ENUM first -- the "called party control" approach in section 3.2 -- this appears to be the most privacy protecting of the three approaches. For a given E.164 number, the only information that must be exposed in the DNS is a URI pointer to a proxy with which the called party presumably has a pre-existing contractual relationship. That contractual relationship will govern how much privacy protection the proxy will afford, and presumably the called party can contract with the proxy to respond to ENUM queries according to rules set by the called party. There are of course security (and thus privacy) concerns about whether the info stored by the proxy is open to attack. But assuming those concerns can be addressed satisfactorily, private contact information is only released or exposed as directed by the called party. An important caveat is that for this "called party control" approach to meaningfully protect privacy, there cannot be unreasonable restrictions placed by national authorities on who can operate proxies that are pointed to by ENUM DNS records. In other words, the privacy protecting aspects of this approach might well be lost if a national authority only permits one or a limited number of companies to operate proxies pointed to by an ENUM DNS record. Ideally, even an individual running a SIP proxy in his or her home should be able get an ENUM DNS record to point to that proxy. The "first" view of ENUM (as a number translation database in section 3.1) raises only limited privacy concerns, especially assuming the "called party control" approach is also a viable option. If one wants to be reachable through the ENUM system but does not want to run or contract with a proxy, one has to be willing to publish at least a single contact method in the DNS. If the "called party control" approach is for some reason prohibited by a national authority, then this "number translation" approach is more coercive (to use ENUM, you MUST publish one contact method for all the world to see). Thus, it is important for the called party control approach to be an option. The "third" view of ENUM -- the calling party control approach -- is superficially the most privacy invasive (because it anticipates that all or many of an individual's contact methods would be published in the DNS). If this were the only way one could obtain ENUM services, this would be very problematic. But, so long as "called party control" is a viable option, then "calling party control" does not present significant privacy problems -- because only those individuals who choose to publish all methods of contact (such as, for example, real estate agents in the U.S., or employers who want their employees to be maximally available to customers) will utilize this approach. Although not a significant concern of the IETF ENUM WG, it is this third approach to ENUM that garners the most criticism by traditional privacy advocates. From the outside, this third approach looks like a open invitation to data mining (and spam, etc.) by publishing lots of contact info in the public DNS system. For ENUM to move beyond such marketplace criticisms, it will be important to make clear that things like the "called party control" option can make ENUM a very privacy-friendly technology. Turning to the second broad area of privacy concern, all of the considerations about how privacy protecting ENUM can be could well be made moot if a national authority implementing ENUM requires onerous disclosure (especially public disclosure) as a requirement to obtain an E.164 ENUM/DNS entry in the first place. In other words, if a fully populated WHOIS type database were required in order to obtain any ENUM entry in the DNS, then the privacy protecting features of the "called party control" approach could be destroyed. The ENUM-privacy-security Internet-Draft proposes (in Section 4) that national ENUM implementations should implement a form of WHOIS for technical contact data. Such a recommendation to national ENUM authorities could be understood to suggest that no ultimate called party should be able to stand anonymously behind a proxy server. I don't think the draft is intended to suggest this, but any finally recommendation should be clear that there is no need for the identity of an ultimate ENUM subscriber/user to be published in a publicly available WHOIS database. Sorry that these comments are coming in only hours before the WG meeting (which I cannot attend because of a conflict). I'd be happy to discuss this more on the list. John Morris _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Nov 18 09:23:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21740 for ; Mon, 18 Nov 2002 09:23:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIEPd026909 for enum-archive@odin.ietf.org; Mon, 18 Nov 2002 09:25:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIEPav26903; Mon, 18 Nov 2002 09:25:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIEMwv26774 for ; Mon, 18 Nov 2002 09:22:58 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21689 for ; Mon, 18 Nov 2002 09:20:17 -0500 (EST) Received: from dick.shockey.us (dick.ietf55.ops.ietf.org [204.42.72.131]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id GAA27839; Mon, 18 Nov 2002 06:22:37 -0800 Message-Id: <5.2.0.9.2.20021118092257.03db6ca0@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 18 Nov 2002 09:23:41 -0500 To: "Enzmann, Mark" From: Richard Shockey Subject: RE: [Enum] Is anyone interested in volunteering as a scribe for t he meeting... Cc: enum@ietf.org In-Reply-To: <9FE11C074413764C898BC7B6C926422B086FFF4B@s30342g004002> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 10:16 PM 11/17/2002 -0500, you wrote: >Only in the event this is the only reply. You are appointed... please see me before the meeting >-----Original Message----- >From: Richard Shockey [ mailto:rich.shockey@neustar.com > ] >Sent: Friday, November 15, 2002 5:07 PM >To: enum@ietf.org >Subject: [Enum] Is anyone interested in volunteering as a scribe for the >meeting... > > > >please ...it will help speed things along on monday. > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Senior Manager, Strategic Technology Initiatives >NeuStar Inc. >46000 Center Oak Plaza - Sterling, VA 20166 >Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 >< mailto:richard@shockey.us > or < >mailto:richard.shockey@neustar.biz > > < http://www.neustar.biz > ; < >http://www.enum.org > ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Nov 18 09:39:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22144 for ; Mon, 18 Nov 2002 09:39:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIEg7C28193 for enum-archive@odin.ietf.org; Mon, 18 Nov 2002 09:42:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIEg6v28188; Mon, 18 Nov 2002 09:42:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIEe0v28091 for ; Mon, 18 Nov 2002 09:40:00 -0500 Received: from nic-naa.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22085 for ; Mon, 18 Nov 2002 09:37:19 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id gAIEeQq4003424; Mon, 18 Nov 2002 09:40:26 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200211181440.gAIEeQq4003424@nic-naa.net> To: John Morris cc: enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] Last minute comments on draft-shockey-enum-privacy-security-00.txt In-Reply-To: Your message of "Mon, 18 Nov 2002 00:57:06 EST." <4.2.0.58.20021117233530.009ba190@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3422.1037630426.1@nic-naa.net> Date: Mon, 18 Nov 2002 09:40:26 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , John, This caught my attention: > ...Ideally, even an individual running a SIP proxy in his or her > home should be able get an ENUM DNS record to point to that proxy. Am I correct in thinking this means that the access model associated with provisioning assume an authentication model which scales to the size of the delegation scoped end-points? Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Nov 18 11:09:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25115 for ; Mon, 18 Nov 2002 11:09:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIGBbV01595 for enum-archive@odin.ietf.org; Mon, 18 Nov 2002 11:11:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIGBZv01590; Mon, 18 Nov 2002 11:11:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIG8Vv01479 for ; Mon, 18 Nov 2002 11:08:31 -0500 Received: from mail.cdt.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25003 for ; Mon, 18 Nov 2002 11:05:50 -0500 (EST) Received: from tosh (cdt [206.112.85.61]) by mail.cdt.org (Postfix) with ESMTP id CE5854900D8; Mon, 18 Nov 2002 11:07:53 -0500 (EST) Message-Id: <4.2.0.58.20021118105135.00a125c0@localhost> X-Sender: john@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 18 Nov 2002 11:03:20 -0500 To: Eric Brunner-Williams in Portland Maine From: John Morris Subject: Re: [Enum] Last minute comments on draft-shockey-enum-privacy-security-00.txt Cc: enum@ietf.org, brunner@nic-naa.net In-Reply-To: <200211181440.gAIEeQq4003424@nic-naa.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 09:40 AM 11/18/02 -0500, Eric Brunner-Williams in Portland Maine wrote: > > ...Ideally, even an individual running a SIP proxy in his or her > > home should be able get an ENUM DNS record to point to that proxy. > >Am I correct in thinking this means that the access model associated >with provisioning assume an authentication model which scales to the >size of the delegation scoped end-points? I unfortunately cannot answer whether the anticipated authentication model will in fact be able to scale, but I certainly am hopeful that individual end points will have an ability to register an individual SIP proxy. I can certainly see that parts of the authentication process could be delegated (perhaps along the lines of domain name registries/registrars). I hope this helps. John _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Nov 18 11:25:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25736 for ; Mon, 18 Nov 2002 11:25:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIGS8N02298 for enum-archive@odin.ietf.org; Mon, 18 Nov 2002 11:28:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIGS7v02293; Mon, 18 Nov 2002 11:28:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIGMsv02096 for ; Mon, 18 Nov 2002 11:22:54 -0500 Received: from nic-naa.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25541 for ; Mon, 18 Nov 2002 11:20:12 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id gAIGNKq4003846; Mon, 18 Nov 2002 11:23:20 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200211181623.gAIGNKq4003846@nic-naa.net> To: John Morris cc: Eric Brunner-Williams in Portland Maine , enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] Last minute comments on draft-shockey-enum-privacy-security-00.txt In-Reply-To: Your message of "Mon, 18 Nov 2002 11:03:20 EST." <4.2.0.58.20021118105135.00a125c0@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3844.1037636600.1@nic-naa.net> Date: Mon, 18 Nov 2002 11:23:20 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > ... cannot answer whether the anticipated authentication model > will in fact be able to scale ... OK. > I hope this helps. No. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Nov 18 14:00:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00020 for ; Mon, 18 Nov 2002 14:00:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIJ2mW11314 for enum-archive@odin.ietf.org; Mon, 18 Nov 2002 14:02:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIJ2gv11308; Mon, 18 Nov 2002 14:02:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIIofv10769 for ; Mon, 18 Nov 2002 13:50:41 -0500 Received: from ams-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29755 for ; Mon, 18 Nov 2002 13:47:59 -0500 (EST) Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAIInEug019478 for ; Mon, 18 Nov 2002 19:49:18 +0100 (MET) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 18 Nov 2002 19:50:32 +0100 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 18 Nov 2002 19:50:32 +0100 Date: Mon, 18 Nov 2002 19:49:19 +0100 Mime-Version: 1.0 (Apple Message framework v548) Content-Type: text/plain; charset=US-ASCII; format=flowed From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: enum@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <71E42651-FB26-11D6-BB82-0003934B2128@cisco.com> X-Mailer: Apple Mail (2.548) X-OriginalArrivalTime: 18 Nov 2002 18:50:32.0251 (UTC) FILETIME=[5F2A58B0:01C28F33] Content-Transfer-Encoding: 7bit Subject: [Enum] Conclusion of the ENUM meeting (re 2916bis) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit New grammar: service_field = "E2U" 1*(enumservice) enumservice = "+" type 0*(subtype) type = 1*32(ALPHA / DIGIT) subtype = ":" 1*32(ALPHA / DIGIT) "type" (and therefore subtype) is registered with IANA, and the registration itself specify what to expect. If we register "A:B" and "C:D", we are not implicitly accepting "A:D". Comments to this mailing list, or me and michael personally. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Nov 18 14:29:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00938 for ; Mon, 18 Nov 2002 14:29:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIJVJj13151 for enum-archive@odin.ietf.org; Mon, 18 Nov 2002 14:31:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIJVHv13146; Mon, 18 Nov 2002 14:31:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIJSZv13003 for ; Mon, 18 Nov 2002 14:28:35 -0500 Received: from nic-naa.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00822 for ; Mon, 18 Nov 2002 14:25:53 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id gAIJSaq4004421; Mon, 18 Nov 2002 14:28:36 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200211181928.gAIJSaq4004421@nic-naa.net> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= cc: enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] Conclusion of the ENUM meeting (re 2916bis) In-Reply-To: Your message of "Mon, 18 Nov 2002 19:49:19 +0100." <71E42651-FB26-11D6-BB82-0003934B2128@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4419.1037647716.1@nic-naa.net> Date: Mon, 18 Nov 2002 14:28:36 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > ... "A:B" and "C:D" (!=>) "A:D" I missed the case against transitive closure. What is it? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Nov 20 11:08:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23245 for ; Wed, 20 Nov 2002 11:08:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKGALu25516 for enum-archive@odin.ietf.org; Wed, 20 Nov 2002 11:10:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKG8Nv25424; Wed, 20 Nov 2002 11:08:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKG3Yv24619 for ; Wed, 20 Nov 2002 11:03:34 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23052 for ; Wed, 20 Nov 2002 11:00:50 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Wed, 20 Nov 2002 17:06:31 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620248BE@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Compendium on enumservices registration Thread-Index: AcKQrsplQnb0K685Sh2PMB3Bw+XkrA== From: "Stastny Richard" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gAKG3Yv24620 Subject: [Enum] Compendium on enumservices registration Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi folks, at the ENUM WG in ATL it was decided not to have the draft-brandner-enumservices-compendium-00.txt yet? as an Work Group Item, but continue it as individual. What I have not completely understood (I am aso not a native speaker;-) was the rationale behind this, and I request help and advice from the list to move our work forward. Since there were only very few comments on the list before, it is difficult for me to get the point I heard serveral different opionions, first the ones to be fixed easily: Some said, the draft was too complicated and contained too many enumservices in one draft. This could be fixed in splitting the document in parts. One for each category or one for each enumservice? Also the categories are not well understood. This will be fixed by removing them e.g. talk will be removed, leaving only voice and video. msg will be removed, leaving email, fax, sms, etc. The rationale behind ivoice was not well understood. This will be fixed by removing it, because it was mainly intended for infrastructure ENUM purposes and could be solved there in another way also. The srs enumservice caused problems. This will be fixed by removing srs:sip and srs:h323 and reducing it to plain sip and h323, allowing just to reference the other two drafts Some others said that it was not clear wich URI-scheme to use by "looking to the right". This will be fixed that every enumservice will get a subtype in the format decided at the meeting, e.g email:mailto or voice:sip, showing the URI scheme. Now to the more serious issues. Many delegates raised concern about the privacy issues and I got the impression that there is a movement within IETF to allow only anonymous pointers in ENUM e.g. sip:agtdswqx@provider.net or sip:+12345678900@provider.net Especially e-mail pointers where considered harmful because of spam Since ENUM is an opt-in service, as defined in all policy frameworks I currently know of, I considered this problem dealt with. Also in the privacy draft from Rich the alternative views of ENUM are stated, so I considered this problem solved. I definitely agree that both called and calling party control is useful, and I also agree, coming originally from the UPT and UCI side, that the called party control is favorable if ALL communication to an person, entity or role can be done via one identifier. But as long as this is not possible, we have to provide the calling party control in addition, to allow the customer to add other information and also to be open for additional, currently only envisaged or even unknown services. I also consider ENUM as very useful for enterprise use, and companies do not have a privacy problem at all. There is another problem: we modelled our proposal according to RFC2916bis and especially after the examples given there, and so did the rest of the standardisation community in ITU and ETSI, dealing with administrative and provisioning issues, and so did the various trial platforms. Citation from RFC2916bis: For example, the Enumservice "presence" (note, no protocol specification) would define the various URI schemes ("im:", "mailto:") can be used and what the service can be used for ("Where is the owner of this E.164 number?"). Another example might be "talk:sip" which can specify that the URI must use the 'sip:' URI scheme and use the SIP protocol to make a voice call (as opposed to a voice mail call or fax call). --- Specifically, a registered Enumservice MUST specify the URI scheme(s) that may be used for the Enumservice, and, when needed, other information which will have to be transfered into the URI resolution process itself (LDAP DNs, transferring of the AUS into the resulting URI, etc). ----- $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 10 10 "u" "E2U+talk:sip+message:sip" "!^.*$!sip:paf@swip.net!" . IN NAPTR 102 10 "u" "E2U+message:mailto" "!^.*$!mailto:paf@swip.net!" . IN NAPTR 102 10 "u" "E2U+talk:tel" "!^(.*$)$!tel:\1!" end of citation If the above view that IETF tends to allow only anonymous pointers in ENUM e.g. sip:agtdswqx@provider.net or sip:+12345678900@provider.net AND especially that e-mail pointer are considered harmful. is true than RFC2916bis is broken, because the above view has to be stated clearly and the examples are seriously and dangerously misleading. BTW, I will not have any problem putting my name, e-mail address and even may street address in ENUM, because the same information is in listed in the phone directory (public on the Internet). And this information can be retrieved also by number. But there is no hint to my occuppation and my buying preference or income. But where I may have concerns in future is giving my e-mail to standard bodies in drafts and mail archives, because since I am working e.g. on IETF issues, my spam e-mails have increased dramatically;-) best regards awaiting your comments Richard Stastny _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Nov 20 12:42:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25752 for ; Wed, 20 Nov 2002 12:42:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKHj9532751 for enum-archive@odin.ietf.org; Wed, 20 Nov 2002 12:45:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKHhJv32704; Wed, 20 Nov 2002 12:43:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKHf0v32624 for ; Wed, 20 Nov 2002 12:41:00 -0500 Received: from nic-naa.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25708 for ; Wed, 20 Nov 2002 12:38:07 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id gAKHenq4012411; Wed, 20 Nov 2002 12:40:49 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200211201740.gAKHenq4012411@nic-naa.net> To: "Stastny Richard" cc: enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] Compendium on enumservices registration In-Reply-To: Your message of "Wed, 20 Nov 2002 17:06:31 +0100." <06CF906FE3998C4E944213062009F1620248BE@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12409.1037814049.1@nic-naa.net> Date: Wed, 20 Nov 2002 12:40:49 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Richard, > BTW, I will not have any problem putting my name, e-mail address and > even may street address in ENUM, because the same information is > in listed in the phone directory (public on the Internet). > And this information can be retrieved also by number. Could you do me a favor and explain what this means to you? Opinion 5/2000 on The Use of Public Directories for Reverse or Multi-criteria Searching Services (Reverse Directories) The url (auf deutsch) is http://europa.eu.int/comm/internal_market/en/dataprot/wpdocs/wp33de.pdf Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Nov 20 19:55:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06573 for ; Wed, 20 Nov 2002 19:55:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAL0w4I28803 for enum-archive@odin.ietf.org; Wed, 20 Nov 2002 19:58:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAL0tsv28712; Wed, 20 Nov 2002 19:55:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAL0oDv28457 for ; Wed, 20 Nov 2002 19:50:13 -0500 Received: from mail.cdt.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06204 for ; Wed, 20 Nov 2002 19:46:55 -0500 (EST) Received: from tosh (cdt [206.112.85.61]) by mail.cdt.org (Postfix) with ESMTP id 6F9F84900BF; Wed, 20 Nov 2002 19:48:50 -0500 (EST) Message-Id: <4.2.0.58.20021120170007.00a33f00@localhost> X-Sender: john@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 20 Nov 2002 17:26:10 -0500 To: "Stastny Richard" , From: John Morris Subject: Re: [Enum] Compendium on enumservices registration In-Reply-To: <06CF906FE3998C4E944213062009F1620248BE@oefeg-s02.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Richard, a few comments.... At 05:06 PM 11/20/02 +0100, Stastny Richard wrote: >Since ENUM is an opt-in service, as defined in all policy frameworks >I currently know of, I considered this problem dealt with. When discussing privacy, some proponents of ENUM argue that it is opt-in and thus we do not need to worry about privacy. Yet at the same time, they have grand visions of how ENUM will be widely used by large businesses, small businesses, and perhaps even consumers. If ENUM ultimately only fills the needs of a fairly small niche market, then perhaps you can say that it is opt in. But if ENUM will be widely deployed and possibly used by many (large or small, corporate or individual), then you cannot say it is opt in. Simply put, if something becomes an important tool in our society and one cannot compete as effectively without it, then it is not opt in. That view would be like saying that there is no need to permit unlisted telephone numbers in the PSTN because, hey, telephones are opt-in (if you don't want to be listed, don't get a phone). Having said this, I generally agree with you that -- so long as Called Party control is a truly viable option -- then the privacy concerns raised by the Calling Party control approach are greatly mitigated (as I noted in my e-mail a few days ago). Thus, it will be important for ENUM authorities and implementers NOT to force ENUM customers into the calling party model. >I also consider ENUM as very useful for enterprise use, and companies do not >have a privacy problem at all. Some companies will be happy to publish all contact info for their employees, but others will view full contacts info as both a privacy and corporate security concern. I know of a number of multinational companies that view their internal phone directories has confidential documents. Personally, I suspect that the companies concerned about privacy and security of contact info will increase, not decrease. The upshot of all of this is that anonymous ENUM entries have significant value (as does, for some, the master-global-white-pages vision of ENUM). John _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 21 01:59:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14438 for ; Thu, 21 Nov 2002 01:59:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAL71A416215 for enum-archive@odin.ietf.org; Thu, 21 Nov 2002 02:01:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAL6x6v16118; Thu, 21 Nov 2002 01:59:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAL6rAv15948 for ; Thu, 21 Nov 2002 01:53:10 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14276 for ; Thu, 21 Nov 2002 01:50:18 -0500 (EST) content-class: urn:content-classes:message Subject: AW: [Enum] Compendium on enumservices registration MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Thu, 21 Nov 2002 07:56:01 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620248C5@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Compendium on enumservices registration Thread-Index: AcKQvGwgoVkHESdkSWaGA6WSfG8zhwAajN3p From: "Stastny Richard" To: "Eric Brunner-Williams in Portland Maine" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gAL6rAv15949 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit -----Ursprüngliche Nachricht----- Von: Eric Brunner-Williams in Portland Maine [mailto:brunner@nic-naa.net] Gesendet: Mi 20.11.2002 18:40 An: Stastny Richard Cc: enum@ietf.org; brunner@nic-naa.net Betreff: Re: [Enum] Compendium on enumservices registration Richard, > BTW, I will not have any problem putting my name, e-mail address and > even may street address in ENUM, because the same information is > in listed in the phone directory (public on the Internet). > And this information can be retrieved also by number. Could you do me a favor and explain what this means to you? Opinion 5/2000 on The Use of Public Directories for Reverse or Multi-criteria Searching Services (Reverse Directories) The url (auf deutsch) is http://europa.eu.int/comm/internal_market/en/dataprot/wpdocs/wp33de.pdf Eric Thanka for the German link, but I am quoting now from the English version;-) Of course we know of these (and other EU documents) and currently our legal department is developing the information necessary to be given to the subscriber and be accepted by him for ENUM (together with the regulator). Citations from the document you mentioned: ... to what is necessary to identify a particular subscriber, unless the subscriber has given his unambiguous consent to the publication of additional personal data". ---- However, reverse searches can prove useful and should not be prohibited as such. With a view to making such processing fair and lawful, the conditions of the Directives have to be complied with: Since the use of personal data in public directories for reverse or multi-criteria searching services is a new purpose, the data controllers have to inform the data subjects about it (Articles 10 and 11 of Directive 95/46/EC). end of cittations You will also now, that DNS is NOT a directory service in the common sense, so it cannot be used by the mentioned multi-criteria searching services. May I also draw your attention to the footnote 1 on page 3: The representatives of the Austrian, Danish, and Portuguese Data Protection Authorities expressed their view that in their countries the practices of reverse searches have not led to specific problems so far. And as far as Austria is concerned, we are offering in principle the same service with is available if you call up the directory service and ask for the name for a given phone number. And I also know, that this is an absolute NONO in Germany and UK. My conclusion is, that IETF is a protocol body and not a national regulator. If it is not allowed in Germany to put the name in, fine. If it is allowed in Austria, also fine. Where is the problem? Thats exactly why we have national ENUM forum and platforms, and one of the main tasks is to develop with the regulator a policy framework according to the laws in this country. This is IMHO not the task of IETF to act as super regulator (one ITU-T and one European Commission is enough. best regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 21 02:56:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24948 for ; Thu, 21 Nov 2002 02:56:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAL7xAw27800 for enum-archive@odin.ietf.org; Thu, 21 Nov 2002 02:59:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAL7vHv27732; Thu, 21 Nov 2002 02:57:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAL7qUv27529 for ; Thu, 21 Nov 2002 02:52:30 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24851 for ; Thu, 21 Nov 2002 02:49:39 -0500 (EST) content-class: urn:content-classes:message Subject: AW: [Enum] Compendium on enumservices registration MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Thu, 21 Nov 2002 08:55:21 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620248C6@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Compendium on enumservices registration Thread-Index: AcKQ+EwCBJlQG+SfTFy3tgGDZynAOAAM0cae From: "Stastny Richard" To: "John Morris" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gAL7qjv27535 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi John, This is a long one, but the conclusion below is IMHO important first the minor issue concerning privacy issues: >Some companies will be happy to publish all contact info for their >employees, but others will view full contacts info as both a privacy and >corporate security concern. I know of a number of multinational companies >that view their internal phone directories has confidential >documents. I know, the company I worked for in the 80ies had a licence of DMS-100, so a had a lot to do with NORTEL (better Northern Telecom and BNR;-), and they really where crazy about their phone directory (mainly because of MITEL). Considering this, we are working on models for companies in ENUM (there is a lot of other issues too, mainly provisioning), including the usage of split-DNS for ENUM. Now to the opt-in issue: This was NOT my idea, although many people in IETF seem to believe this, it was the idea from the Report of the Department of State ITAC-T Advisory committee Study Group A Ad Hoc on ENUM, July 6th, 2001, (puh), BTW chaired by Gary Richenaker, now chair of the US ENUM Forum and chair of ITU-T SG2 Q.1 (from Telcordia), proposing the US ENUM Forum and stating: 4.3 Opt-in service for called user. The assignee of a number must choose to participate in ENUM before any NAPTR records for the number can be populated. This is important since records in ENUM are publicly accessible via DNS query. The opt-in process should be designed to ensure the following: · Users can control privacy and security of their information. · The default condition is to not include NAPTR record information. · Any request for inclusion must be authenticated as being from the assignee of the E.164 number. · Inclusion of NAPTR record information must be reversible, allowing the party to remove the data from the DNS in a timely fashion. 4.4 Opt-in service for calling user and service provider. The crucial part of Opt-in for the calling user and service provider is whether or not to query ENUM and then whether or not to make use of the results. The following approach is proposed for telephony services: 1. No originating party (e.g., a calling user or a service provider) is obligated to perform an ENUM query to complete a telephone call to an E.164 number. 2. A party making an ENUM query, whether a calling user or service provider, is not obligated to use any of the services in the NAPTR records returned. 3. All E.164 numbers must have a Public Switched Telephone Network (PSTN) point of interface. (For geographic numbers this would be an end office or tandem.) This was taken over in principle as policy by ITU-T and slightly modified by ETSI in TS 102 051 "ENUM Administration in Europe", and therefore by all regulators dealing with ENUM issues, and therefor I have to live with this, as far as "User-ENUM" is concerned. And because I fully support your arguments, I tried to raise these issues in draft-stastny-enum-scenarios-00 in IETF, proposing a User-ENUM and an infrastructure ENUM, with no response (it was not even put on the agenda). The infrastructure ENUM would only contain records without any privacy problems, therefore would not require opt-in and could be used by operators for infrastructure purposes routing, NP, etc.). ETSI is currently progressing this work in SPAN with a Work Item on ENUM for Network Routing. One reason may be that a majority in the US sees e164.arpa as infrastructure ENUM anyway (which is seen differently elsewhere, ITU and ETSI sees e164.arpa as User-ENUM), so they see on one hand not the reason for an additional infrastructure ENUM, and on the other hand do not see a reason for the services provided in the Compendium, because they are really not needed in an infrastructure ENUM. For infrastructure ENUM I just need sip, h323 and tel with the James Yu extensions. For User ENUM I need the Compendium services. I think there is a severe misunderstanding here, both sides always talking differnent things. best regards Richard Stastny -----Ursprüngliche Nachricht----- Von: John Morris [mailto:jmorris@cdt.org] Gesendet: Mi 20.11.2002 23:26 An: Stastny Richard; enum@ietf.org Cc: Betreff: Re: [Enum] Compendium on enumservices registration Richard, a few comments.... At 05:06 PM 11/20/02 +0100, Stastny Richard wrote: >Since ENUM is an opt-in service, as defined in all policy frameworks >I currently know of, I considered this problem dealt with. When discussing privacy, some proponents of ENUM argue that it is opt-in and thus we do not need to worry about privacy. Yet at the same time, they have grand visions of how ENUM will be widely used by large businesses, small businesses, and perhaps even consumers. If ENUM ultimately only fills the needs of a fairly small niche market, then perhaps you can say that it is opt in. But if ENUM will be widely deployed and possibly used by many (large or small, corporate or individual), then you cannot say it is opt in. Simply put, if something becomes an important tool in our society and one cannot compete as effectively without it, then it is not opt in. That view would be like saying that there is no need to permit unlisted telephone numbers in the PSTN because, hey, telephones are opt-in (if you don't want to be listed, don't get a phone). Having said this, I generally agree with you that -- so long as Called Party control is a truly viable option -- then the privacy concerns raised by the Calling Party control approach are greatly mitigated (as I noted in my e-mail a few days ago). Thus, it will be important for ENUM authorities and implementers NOT to force ENUM customers into the calling party model. >I also consider ENUM as very useful for enterprise use, and companies do not >have a privacy problem at all. Some companies will be happy to publish all contact info for their employees, but others will view full contacts info as both a privacy and corporate security concern. I know of a number of multinational companies that view their internal phone directories has confidential documents. Personally, I suspect that the companies concerned about privacy and security of contact info will increase, not decrease. The upshot of all of this is that anonymous ENUM entries have significant value (as does, for some, the master-global-white-pages vision of ENUM). John _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 21 07:21:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29227 for ; Thu, 21 Nov 2002 07:21:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALCNX110653 for enum-archive@odin.ietf.org; Thu, 21 Nov 2002 07:23:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALCLMv10609; Thu, 21 Nov 2002 07:21:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALCIDv10499 for ; Thu, 21 Nov 2002 07:18:13 -0500 Received: from nic-naa.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29111 for ; Thu, 21 Nov 2002 07:15:31 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id gALCI0q4025978; Thu, 21 Nov 2002 07:18:01 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200211211218.gALCI0q4025978@nic-naa.net> To: "Stastny Richard" cc: "Eric Brunner-Williams in Portland Maine" , enum@ietf.org, brunner@nic-naa.net Subject: Re: AW: [Enum] Compendium on enumservices registration In-Reply-To: Your message of "Thu, 21 Nov 2002 07:56:01 +0100." <06CF906FE3998C4E944213062009F1620248C5@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25976.1037881080.1@nic-naa.net> Date: Thu, 21 Nov 2002 07:18:00 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Richard, Thanks for quoting the English version. > You will also now, that DNS is NOT a directory service in the common sense, > so it cannot be used by the mentioned multi-criteria searching services. I honestly don'k know what the authors ment by "directory service". It seems possible that they ment exact match as well as inexact match semantics, and didn't distinguish between distributed loose, converging consistency, and centralized store for repository state. The dig tool makes queries for more than one type of record. I can't speak to the author's intent, nor to how the language of this document is correctly applied to our context. Having met several of the authors, I do have the sense that they do have some views on the applicability of their work to the DNS. > My conclusion is, that IETF is a protocol body and not a national regulator. > If it is not allowed in Germany to put the name in, fine. If it is allowed > in Austria, also fine. Where is the problem? In my view the protocol problem is to create mechanism(s) that allow the application of policies. These may be cost-recovery policies, or policy based processing algorithms, or access controls, etc. Borrowing the "internationalization" -- > "i18n", "localization" --> "l10n" convention, this is "jurisdictionalization" , or j19n. What, if any, are the j19n considerations of some protocol, e.g., dns in the service of enum, seems to be the question at hand. > Thats exactly why we have national ENUM forum and platforms, and one of the > main tasks is to develop with the regulator a policy framework according to > the laws in this country. I can't speak to that, but to the degree that national jurisdictions have policy scope, it seems reasonable to treat them as any other form of policy. I'm aware that the rational has been offered that the value of consistency is greater than the value of national jurisdiction for the dns. I don't find the claim particularly compelling, but exists. I'm only interested in mechanisms to allow j19n. I take for granted that some jurisdiction has a policy it would like to deploy. Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 21 11:05:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07733 for ; Thu, 21 Nov 2002 11:05:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALG7T625190 for enum-archive@odin.ietf.org; Thu, 21 Nov 2002 11:07:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALG5Xv24539; Thu, 21 Nov 2002 11:05:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALFmKv23304 for ; Thu, 21 Nov 2002 10:48:20 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06962 for ; Thu, 21 Nov 2002 10:45:35 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Thu, 21 Nov 2002 16:51:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620248C8@oefeg-s02.oefeg.loc> Thread-Topic: [Voip-disc] FYI from japan Thread-Index: AcKOya2BLIYFsOmxS92dcu8fZfFXQACpDZop From: "Stastny Richard" To: "Richard Shockey" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gALFmZv23313 Subject: [Enum] three different views (draft-shockey-enum-) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Rich, in your draft-shockey-enum-privacy-security-00.txt you point out three different views: "Even within the technical community there are differnt views of what ENUM is and what it is designed to accomplish." and then you list 3.1 number translation database 3.2.called party control (ENUM subscriber) 3.3 calling party control (ENUM user) and you link these different views to different security and privacy issues. This is sofar ok, but IMHO the views need more differentiation (there are at least 2 x 2=4): From the discussions during this week at the IETF55 and on the list, we may have at least two dimensions, so we may end up in four corners: There is on one side the (say) horizontal axis of called vs. calling party control, as you mentioned. On the other hand there is the (say) vertical axis of ENUM subscriber control vs. service provider (operator) control of the domain and the NAPTR records The latter dimension is linked to the opt-in principle With ENUM subscriber control the opt-in principle is required, with SP or operator control the opt-in principle does not work, because to establsh a feasible service, all your subscribers, or ported numbers or whatever, need to be in ENUM and therefore privacy is mandatory. So if you now draw the four quadrants (mentally, it hard in text;-), 1. in the upper left hand corner you will have calling party control and ENUM subscriber control (opt-in). What is required here is the bandner-compendium. The privacy is taken care of with the opt-in principle of the ENUM subscriber. 2. in the upper right hand corner you will have called party control and ENUM subscriber control (opt-in). What is required here is a service resulution service ala sip or h323. It is up to the ENUM subscriber if he takes care of privacy by using URI not exposing information or not, and if he adds additional information using enumservices from the brandner-compendium. This implies, that the two approached need to be compatible, what they are. 3. in the lower right hand corner you will have called party control and SP or operator control (no-opt-in). This will be necessary for all applications using ENUM as IN-replacment and for network routing purposes. Because the user is not asked wether to be in ENUM or not, privacy is necessary and therefore only URIs shall be used which do NOT expose information about the called user. These are mainly sip, h323 and tel records with the extensions proposed in draft-yu-tel-url-06. eg sip:anon1234@prov.net sip:+1-xxx-xxx-xxxx@prov.us tel:+1-800-xxx-xxxx;cic=+10234 the latter may also be used from the PSTN via LDAP and a mediation device SCP-ENUM 4. the lower left hand corner is interesting. It may either not be applicable or may not exist in public DNS, but it may exist within networks, providing the services from the brandner-compendium packed to the user in "ENUM" without asking him. Since the data is not exposed to the public, no privacy concerns and also no regulatory issues exist. Especially mobile operators are happily exploring this corner. IMHO many of the misunderstandings during the discussions of this week just simple came from the fact, that one party had in mind during the discussion e.g. corner 1 and 2, while the other party had in mind corner 2 and 3 and of course did not understand what the hell the other party is talking about, because both were sitting in opposite corners. I include myself in not understanding what the other corner is talking about, but now I hope I got it;-) Since I consider the draft-shockey as very important to discuss and clarify these issues, I hope that this mail may contribute to the draft-shockey and also may open a way forward in the discussion on the enumservices (variants) and why all of them are needed. It is just depending on the corner you are sitting in. best regards Richard Stastny _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Nov 21 16:51:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22186 for ; Thu, 21 Nov 2002 16:51:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALLrNR18874 for enum-archive@odin.ietf.org; Thu, 21 Nov 2002 16:53:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALLpRv18794; Thu, 21 Nov 2002 16:51:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALLk0v18621 for ; Thu, 21 Nov 2002 16:46:00 -0500 Received: from mail.cdt.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21888 for ; Thu, 21 Nov 2002 16:43:14 -0500 (EST) Received: from tosh (cdt [206.112.85.61]) by mail.cdt.org (Postfix) with ESMTP id EC4224900DA; Thu, 21 Nov 2002 16:45:04 -0500 (EST) Message-Id: <4.2.0.58.20021121163228.00986610@localhost> X-Sender: john@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 21 Nov 2002 16:45:38 -0500 To: "Stastny Richard" , From: John Morris Subject: Re: AW: [Enum] Compendium on enumservices registration In-Reply-To: <06CF906FE3998C4E944213062009F1620248C6@oefeg-s02.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Richard, a brief comment, with more conversation on privacy in the coming weeks... John At 08:55 AM 11/21/02 +0100, Stastny Richard wrote: >Now to the opt-in issue: > >This was NOT my idea, although many people in IETF seem to believe this, >it was the idea from the Report of the Department of State ITAC-T Advisory >committee Study Group A Ad Hoc on ENUM, July 6th, 2001, (puh), BTW chaired >by Gary Richenaker, now chair of the US ENUM Forum and chair of ITU-T SG2 >Q.1 (from Telcordia), proposing the US ENUM Forum and stating: Yes. To be clear, I did not think the opt-in analysis was your idea -- I appreciate that it has long been an analysis advanced by ENUM proponents. But I think it has only limited validity, and in any event does not avoid the need to develop and offer privacy friendly options within the ENUM structure. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Nov 22 22:33:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11597 for ; Fri, 22 Nov 2002 22:33:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAN3a8I26607 for enum-archive@odin.ietf.org; Fri, 22 Nov 2002 22:36:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAN3Zpv26588; Fri, 22 Nov 2002 22:35:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAM4W4v09955 for ; Thu, 21 Nov 2002 23:32:04 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05532 for ; Thu, 21 Nov 2002 23:29:06 -0500 (EST) Received: from l20058 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H5Y0016DN5R6O@mta0.huawei.com> for enum@ietf.org; Fri, 22 Nov 2002 12:29:53 +0800 (CST) Date: Fri, 22 Nov 2002 12:26:39 +0800 From: Li Tianbin To: enum@ietf.org Message-id: <000d01c291df$5ee389e0$47904c0a@huawei.com.cn> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: multipart/mixed; boundary="Boundary_(ID_7eKuDHyZ3m/5ZCy7eKse1g)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Enum] Help - A question about ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_7eKuDHyZ3m/5ZCy7eKse1g) Content-type: multipart/related; type="multipart/alternative"; boundary="Boundary_(ID_itkMQiOPwLT1/vPNMumIqg)" --Boundary_(ID_itkMQiOPwLT1/vPNMumIqg) Content-type: multipart/alternative; boundary="Boundary_(ID_pcjA+BLF6Di/XcSBQDOwmg)" --Boundary_(ID_pcjA+BLF6Di/XcSBQDOwmg) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 19TIuyANCg0KRGVhciBzaXJzLA0KDQpDb3VsZCB5b3UgaGVscCBtZSB3aXRoIHRoZSBmdWxsIG5h bWUgb2YgRU5VTT8gU29tZW9uZSBzYWlkIGl0IGlzIFRlbGVwaG9uZSBOVW1iZXJpbmcgTWFwcGlu Zywgc29tZW9uZSBzYWlkIFRlbGVwaG9uZSBOdW1iZXIgVVJJIE1hcHBpbmcsIHNvbWUgb25lIHNh aWQgRWxlY3Ryb25pYyBOdW1iZXJpbmcgTWFwcGluZywgYW5kIHNvbWVvbmUgc2FpZCBFLjE2NCBO dW1iZXIgVVJJIE1hcHBpbmcuDQoNCkkgdGhpbmsgRS4xNjQgTnVtYmVyIFVSSSBNYXBwaW5nIGlz IGJldHRlci4NCg0KSSBzZWFyY2hlZCBmcm9tIHlvdXIgV2Vic2l0ZSwgYnV0IGNhbm5vdCBmaW5k IHRoZSBhbnN3ZXIuIA0KDQpJJ2xsIGJlIGFwcHJlY2lhdGVkIHRvIHlvdXIgaGVscCBhbmQgcmVw bHkuDQoNCkxpIFRpYW5iaW4NCkZyb20gQ2hpbmENCg0K --Boundary_(ID_pcjA+BLF6Di/XcSBQDOwmg) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT7X1Mi7PC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1aXY9 Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1nYjIzMTIiPjxCQVNFIA0K aHJlZj0iZmlsZTovL0M6XFByb2dyYW0gRmlsZXNcQ29tbW9uIEZpbGVzXE1pY3Jvc29mdCBTaGFy ZWRcU3RhdGlvbmVyeVwiPg0KPFNUWUxFPkJPRFkgew0KCU1BUkdJTi1UT1A6IDVweDsgRk9OVC1T SVpFOiA5cHQ7IE1BUkdJTi1MRUZUOiAzMHB4OyBDT0xPUjogIzMzMzM5OTsgRk9OVC1GQU1JTFk6 IMvOzOUsIFRyZWJ1Y2hldCBNUywgVmVyZGFuYQ0KfQ0KSU1HIHsNCglNQVJHSU4tVE9QOiA1cHg7 IE1BUkdJTi1MRUZUOiAtMzBweA0KfQ0KPC9TVFlMRT4NCg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuNTAuNDgwNy4yMzAwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNm ZmZmZmYgDQpiYWNrZ3JvdW5kPWNpZDowMDA3MDFjMjkxZGYkNWE0ZTIzNDAkNDc5MDRjMGFAaHVh d2VpLmNvbS5jbj48SU1HIA0Kc3JjPSJjaWQ6MDAwNjAxYzI5MWRmJDVhNGUyMzQwJDQ3OTA0YzBh QGh1YXdlaS5jb20uY24iIGFsaWduPWJvdHRvbT4gDQo8UD48L1A+DQo8RElWPkRlYXIgc2lycyw8 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkNvdWxkIHlvdSBoZWxwIG1lIHdpdGggdGhl IGZ1bGwgbmFtZSBvZiBFTlVNPyBTb21lb25lIHNhaWQgaXQgaXMgVGVsZXBob25lIA0KTlVtYmVy aW5nIE1hcHBpbmcsIHNvbWVvbmUgc2FpZCBUZWxlcGhvbmUgTnVtYmVyIFVSSSBNYXBwaW5nLCBz b21lIG9uZSBzYWlkIA0KRWxlY3Ryb25pYyBOdW1iZXJpbmcgTWFwcGluZywgYW5kIHNvbWVvbmUg c2FpZCBFLjE2NCBOdW1iZXIgVVJJIE1hcHBpbmcuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj5JIHRoaW5rIEUuMTY0IE51bWJlciBVUkkgTWFwcGluZyBpcyBiZXR0ZXIuPC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj5JIHNlYXJjaGVkIGZyb20geW91ciBXZWJzaXRlLCBidXQg Y2Fubm90IGZpbmQgdGhlIGFuc3dlci4gPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5J J2xsIGJlIGFwcHJlY2lhdGVkIHRvIHlvdXIgaGVscCBhbmQgcmVwbHkuPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj5MaSBUaWFuYmluPC9ESVY+DQo8RElWPkZyb20gQ2hpbmE8L0RJVj4N CjxQPjwvUD48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_pcjA+BLF6Di/XcSBQDOwmg)-- --Boundary_(ID_itkMQiOPwLT1/vPNMumIqg) Content-id: <000601c291df$5a4e2340$47904c0a@huawei.com.cn> Content-type: image/gif; name="=?gb2312?B?x+/I1S5naWY=?=" Content-transfer-encoding: base64 Content-disposition: attachment; filename="=?gb2312?B?x+/I1S5naWY=?=" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhWAI8ANX/AMDAwP//zP//mf//Zv//M//M///MzP/Mmf/MZv/MM//MAP+ZzP+ZZv+ZM8z/ /8z/zMz/mcz/Zsz/M8zM/8zMzMzMmczMZszMM8zMAMyZ/8yZzMyZmcyZZsyZM8yZAMxmZsxmM8xm AJn/zJn/mZnM/5nMzJnMmZnMZpnMM5mZ/5mZzJmZmZmZZpmZM5mZAJlmZplmM5lmAGaZmWaZZgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAAAALAAAAABYAjwAQAb/QIBw SCwajwDBQclcOpsCpnQ5jVKp1ezVys1Gv+CwGByIlgXnshrNXrvbcLUcLQ/Y7/i8fs/v+/+AgYKD AQB3hoV2houJjI6NkIuShZNIlpeYmZqbnJ2en6ChoqOkpZpSSk5PT1oIFwOpXUt5WFplWwG1tWNs vQdpAgbBZnHFbmttdclzBgHNv87Rzc500dB504Taf9l23X2PeIbZ5Irm54iMkJHs6ZSUj0Lv8vRC BkIFDwAT+A4GDhMmBOBHIWDBggAKTlCoMKDDgBlUPCxIYkKJCRkmVDQYUEVDjhMdkvj4cALAfSYn PFjYUUMJFSpKHPQo06NFjR8rXqQw0mBM/5cAbBYsUJKgSZgeKbjUQNMlhZ9PmcJ8WsIphZ0LKVxl qvSpVo8el9ZUKlNDV61m03ZVy3YthaAlSlRQUaHEiqp1N5TYwIHFBhaAN1AwocHEVQ4WEiu2gPhX hcWLL1iQjEKy4seI6TygEICzgQePQ1uogDhxaciPE29QXBoz49EcRK9eLZrDCdgnSI9WbWH1it27 RQOvEDp34gon/iJXbgJzhQ2haRMfXYHF9OYVTMQOjZ06dejTn+cmbt1C8+7ZiadXv5449uYbmq9Q byI+8fnY2UOnwP6++//zZWdfBStgB0EFEAy2AQQMEsfggeo1iKCDAcx3IIMUCFBgZzIVuP9BgHZV MJgh/OwTAEADDeRAAQCtpBVLC/nDEkApHcQRQ0XlyNBIKmjgEAU0rvQQQDQaBJCNQy5EAldgHbTP ikeapNBLVN6kJE9QzRjQA0Ttg1RVP8Hkkk0TIDWVlEQ+tORLJDHEU0NafZUBBXNWpZRZbuWpVpwa pMUWAHXFlZ0JBc63wnx0qWCCCiyc0ChggMnQwQUdoDDpaaUdMA1nEBgw2aeTflpBZ7mQyhlnpHqa WmqLlRYbb309B9trpDnHGKuvrdZbcI+tFturugV73HTBFasedRxo9xwL26kXAYLUhRcae6NZ19xo 461q7LCk1becBQH2Bx57Ab5HH4Hrxbf/XbjoeosfdB/291655fpHqIAXQhCfAA4eCB2EyPkHXgne UlAufwYTF59eKwDgAAD6TMBiQFCqdGOMWxp5pZVRXozTRCnQCRKcJJSQAZhUeUUTSA+BKZHDTwq0 Ij8rwizEwwHFnJJDbMZk00AF+czmjyFdtBNYZKaZUpEWIeUSjUAaJFPISOOZFUtofXVW1m21pScA BMdpAsFyyUXYYHINNtgJJkDKAqUXcHBBAh10YEHdk046KmcCPFDqAQ8IQMEBj3ljqjMPNMMZaMPa ceodfnvm2quMWccBX7XuNhutwQGLWOayijZda9aVfhxtyTZL2m0TWsBvhMT2591j1hEI/9xrkHl+ XHmhi6uwegMOWF9+55HLHqQWMMtBbON6O+Fz+a0XPXjQ/dpXX4B10Fqtv/aqmui8gnveYNnxR+ii FQzBJZcVP1yQAzYWScFKm7kIo41vXpXSSvBbbBJRBuEJS0aypJGkYGgO6dj9WEKlMQltBXDiB81Y BEAaReklX+LKRZoWEy3pw2FG+siU3rezGllwIUkJyEaUdBOjzYlHT+lRXMRiMPzFiU8vOouftmYW QJWtLiIS0dgMYxjiyGR8Isqe9i5VN0rV7W6TkkwFDtCpvv2iigHoVOL4E4BRgaYzfQtA5DqjRcVx qla42pxtlveazyFmjawaHXG696rN0f+mN9P5zQliw4LjIGYDG7jNbPZ4nAPt5kDPchC1ngWBep3m Aq5QjGVYg5pZ8WpatcvcecJVoEyqx0PQI43ylNeXxTzmNrlJ0AZewAJWMouVrmSB9lrAghb0xZa2 PM6u2giZ3PUyMQiowAAsEExTjmY+ZptL+oTAJZhFzX0Ss1//NmMx+mHMmkDSn/5kQrEaWUkkO8If R6LUMRjeLGcDlMpF7LdABgbkIj0h4JtSQAKJWOSAMFmBCkvQkzdRDCU7SUGZ3vcRlEgwainUGJIU ApaqDC1oXsGTWQpwQxzeaS19ytNb0tM21jgqeYtxlKNq2Ue2nQBub7tAC5zIAcIZIEH/Bxgcv7rY xWaM6qXCyFDiEgc4A7y0M57pTOK05SpcGfUyfzTNrSyXmN/oZgWfcx2CCCcA11ngAM/i167AF61j hWdbihQNwLr6n2MCD1fEXAwCKGka0UWPPc16q3vs8xfsXc9tzBpp8k7A1+q8klmABQwHVuBK7Am2 sLjsQAsWq1i8ORZucmMrB+xmmWEOUzGXnRaB5vMhg9mHLhAkkKI0UCDS6mVh8oFACQ70ACIaLEEq WAFpVyAYEyQIYYFLwNwugAEPJAABA/AADFzggg7EoAUeqJsHWhAC5k7KAxeA7gWmWzfkTtcDMYhi AnSLt+ROirvTpS4LTmaB5LogvHSz/1sFfGQRnlQgihjYbQIg0EKNWAC5HSiueTVAAnrCJAUp0EAL osjbDniAA2LyCAdckNwKEO1NtQyBC+pykAALdFQCgNtug9kVrLllT1nDoQYSMh+xyYR8MklbdVAJ mNuY4KSgohQK7hu3lV4qbig4zX13zNbUGCA1g9tMZz5TASJ/xjM7/TGmOMeY3LwxNMuL1RvBpUsL DGAAELAABBJJnETqajzbASv4pDW70ACMPmUG1nPkSC24/ic75oHzm3tnrwGpjrPoIo9t8qxIgB2I tpCC5WEFHcsBEcgE8ikevQ5Vr9ToGDFr1bFi1qqYha2ALjUUDHEG4yFklpi2jE4UYf/qoyhFFWov jOasoq6iF8PIdlEW2kyhGL1MUyBhwQIYQAIEgIDHNsMQd0NAFAiQayfiNzbyiK727gZdeNgDbxeI At0GLGxLGECx6N11hptr4LntOgEtsIAQLJBdA+e3AwhwxhHK8Ji6xSC76ba1ra2wilVAYQta6IIV vIEKJdyiC8IYhr+lgIwxAIMYAR/GLc4Q8Dc4HA5xUMYdqhEIOkBjGs0IhuHyQPFteDwPiBCEOwJQ gDuQAxH3OEQi1hGPdjQiHJKohMzh4ex1y/vmOM+5znfO854XYQMHiHcm7E1vVOD7AAcgpmTAwAo6 IKLkXzi6LP5N8Kjz4uC/GDgaqFD/qod73esUp4PYo4EGYWy8GWZHe9mpYTiKf2Mb33i7IOT+h5BH Y+MA6EbI956OvrfcEYBvBz3mUQ/Al9xhEzvRP/JB0f4phH8BMYDHchSSAZJkgT3CkUJoVJF+hsTx /ZsIQBw6Jm4WhaBW2iBF2tteGeKo8lpyGVd89BWnYO0mpWcKjIpyEZcM9Cd2kiFXdMhD4mf0+GjB U1AOnZ2qoA8t8sGro1YAKcmchtKv+TG7JTndyURxMQdSnDPEL+Qx72bKfhQOG/vYmqTeynOg2+Wv epOcrfYxfF/V1qpER1dwpWc7WfY8ZNVm0qIw5uF/+1cr0BFnygIenoQu4NEc2fI7/+nBLtgRgWfF HolmH/jhH6BhL+1yMIbyOheCIH6mIRPiZ9BRRPXRaR8SW/diPh9SIPswBBOweCiCJgFkMeJEQC9R JhoQEWTSEFXREx2BQT5jFgmkEReBFFThMylDQhhTQibhABXzJB5Rgw+jhWmiNGBCJR2UMUuTEgkx Tj9SEUGzFABAFFzRhVFTEC8xJkiyMfxEAVSzJG/BIjZCemthJxfFFl3DQwDgWoj2HHKBaXHifCYw A23TKHx1UqEyXZNlN8s2GjQlDH5DRcJQAdRliYlTKj+FZMIwHFN0Vc+TKkL1Y5NDO230KtvhRsKh K9MRSOExWO+nG9zSR6LhSZozK//EUVVZBiHhszloRGb+YUyVBBwBkjrQMy4CUmf9MWfYwS5+tUeD woFr1h7mMlcrqI1CBCDRSGV35FTlcUfwNzyIZj4KIh/kM2IP00wUQEErsQ8rQRRucjXZJDXtVTKm RzEF4SJQAyNMI08kYEAvsSa+N4ZzCBKkRyVzaDNDUCQzc1ADRHph2BBCcFAfsRM6cSVksoREQSTy UyZgchOPFxBM4VAwEXxLcRV34mG0d0N74jUiBihEVBdjcxUiojaCQjZCVDly40R541hDORq/kHUZ kguOkUXiNziHAzhQ6Tef0Qx+I0bT4De4eBmWxBjaoZXVsVW7wjy7g0ZJ5T2pwzv/u/IbsKEutWId CGBIXVYBEYBVAahlFaBVdlmAaDQZrhBJbKVUYKlZvIIe40KLHNUuCxNnnEQg10NLUXZ/1JEg/pGN AUJ9sSRYzEJLsrSZxcIaukE5vbRkUpV0vQJEhlIXyHQzKSJBCVGD10Q0PNg/RwI/2TQSRmMR/PVM 7tMxUWN6EqECS6ICc5IxoUc0BLQyRRIXMYEkxblQFjQxaFgyCwGGCYaESeOPKBE1LBFb7dN4IZmP AKFPBmGEl/cjMwQVMtQkGXUQcUJRxbdDEhUnYNMcZTMY23gtqGQbLlYBI7ACJ7BYkwhFS3Q3cqM9 lnGXSTkqUWkAGdKgpjINN4U4/2bHU3HUmachi7xUR7TyOXN0K75BK1hmgsZSHGU2LLAxR18piw5S SKHxLBbAZamRAMRkN5P2KZD0KX/pGqIzLXgUjXMEKaWEmUEKL8sTWHi1V48yUm7zAqxkV4CFPbQE A9eTla6CO5IGmL+EABGQVhGgpUa1MOWDKNlRGNlhKJ51LxC0GfeCIKCxGRDwAB+4WibwAIfCHxBQ RKBhWxTAWhegX90llBzgbBYAAwPWAXUxAcxWN4IREAUAADElQV2UAAPQa8JlqFIBEJzoRCzgTgIE TyyUFAHFh7J0bv1okhYxWdl1IE1jQQixe1RBHNXlYAwhAIrFATzBFfVkFQkxJ/82RCchFogyyTUb VWLzg2hFdEqK8Yh8lax81X2SQSkntVKUAkVx80QIglPBUEVT+QAxJaFHdjhTua1TWRu+hBjspxu6 Yj1t2UakEVUCwEhzeWbFknSkKTuCOWbSApewMzu1kyxuph/rES1l1i6a9Va8E44oeoE+Wh220WKN 0jYnAFVQZaSG1ReFxQLUd1iBFkszACl5M62/ZKWLYVkhqxqHAkQqcFr1wR+IUh974WofMmqI0mrx USDowmiEcijx4hGh1RwGg2h2kTCeNiKg0EUVMGC7JV/TFV/PFV7RlmsGtlKwQF3JtV1zk1zK1l3m FgMugFzbpVvRlbUuAAOTslb/HVpdvuVExfVd0kU30MVdjiV0eUeURkmU1ZVdx5Vd3uVEF3AAGiap Mjqp6aZkrtNzRRcLiIt097a4ROcEE7cFR7dwAxdwVJBwWHC5ZsB1mstwFmcHxvC5cxBxc+C5hJBx GLd2Gnd32oB20tC6rMu6d4dxZwdyKqcOdscHeycOK+cO8vByLvd3wEt4NIcJNTcEhOdzyJu8yru8 zHtzi5tv9vYEa/W8leu5+CYL2FsFkmt0bJB1TJAGS5BwnttwoEsMozt2yyB2shu7bUe600AH3UB3 Hze/fTANeYcH2VBy64C7K6dyu/u7ANx3Lzdz9XC8Q3APa2gPJiKPFORhMWKP/wsBwZS3kJT3IwZV wRjcTRr8JBPzIxVVUVlRnpXXq+z5IiV0Eh58Q7eXQyr8wSEcwiDMwjD8wTRcwzZcwzinuNRrddEr o327w3agv/92BVRHuVyQC/vGdFa3vUbMueZrvmCHDKN7DBKXdtUAu2UQd3jQcd3QcYGgxfiLDbMr xvh7u3enDnpwuyMXwH8XwMcbCTInc/fgDziDgzj4jxwxEBLjPyKkI2dohxixQppnegL0ehyxQUyD xyKMQj5TJnqhPzcSkPBUECFzEz2xagoheYwqMRWTEkyRkhnxFLiJQXLohDvxhBtUNFIhfD3DJBIV fBilJ8KafEqhCV2EdEh3Cf9NBwVcEL1KN731Zga/1r+6gMRSYMQC57278L1al3VZl8VfQL5RXAxj d76kqwbva3a0kMVsZ7phjA1eHMbhvHEmR8b1ew78q79mDA60iw6C53Lw3Lu+W3hFAAkswkxruCL8 8w//kI+bFz8RBHvlSRJoeD/Dt3un13kss3kaLIWNnDRW+McxYTRY4RAeoROkJRH5WBJKE0OfDCZL 4TOXlpA5MQFjMsEP8dFg0ZKZpxaZN8sf9ocUYABqQWI/azBBaxixxR9GCliIUgKStRiJIwAQgH2f MmNO20uj4gx7wxlFRgFeiVSQcUd+REjyx6545H5R5YphCWVOpUscUJfa4h3/iXEgghQtl4MfvSEd qqOL1DIu1HGwmvUbC0iWARNn0QIeXdWN+QEevzE8/+HX/1E8eWYoBcNnAnKy7SE8xLEZBFKCoAEB WQQ7JoggdroCDZIgJlAhm6azLRgfx9owb7GG7DMQ/8DHjrdAFLyQC2WbKK1CEGUQMMNAHRRO4iQk ZChB/TMmUIJ4Y2iFDVGdcEiS7HV7FDMxMWQ0BwFDMFEIHBQ1kIcj9eRQD8ZAJ5ObY3EjLV0WZCHT OxTTfwKq6fjIdzFqOO2wncQCHUspKyWao7EpXTQZznoBlQFM7y1G3jA/zqBFAVBl56djwuIrn2kB 1rg8q/JkJ4oY9ccbv6Gh/+VRpWMtHAkYLNWROWypSJH5GPr6HROoWRG4LatxgchyjBWOLrGxjQ9I V+sRIAMIIJv0Sc/zZ6FEKOYzmelxZnfpZq/zi8fCH0ZUgZ/EaiUmH+VjAvzwQUdOQS0SeSGkJfKz Qam8ekbjEZUsEhrBXxqtgzDShKWc3B4Repd3EjjjmjRCBI062yisNCQp0o0nkFX4Tv4Dm8stFUjC wUKSnGJS0YNsmx49jxR1NXayFF4DiOCNJ7WMNoOtYjX0E4TisI34NtimUipViYnhODnVRWiQGBdw AqFCHHe3OGSHKlqp1LfSoyISDeQKUmFpSRhKf7qEoQLuf3AEPsZBZV51f/8hPn9Upks8uqPQEy3E Ixz+PS3jgTkVjmcw/mbxYS2HCYKKLY1zho3dqIHyci6DHY35wS/z8R3J3qHAYy6cNi/lEx8PQwns kw8HtQ/ayccx4s8f43mSDCMF3RNBIu9XziPEHYeqxzLyLocqMTHPuYUwM+ZScsKwjUEVnTMk4o8j zKlC0e4mRIS4CROeNyalrO9iMRU5ZNJxwvHDaXzFp0MJIROHpjZjg5NAZPIsALEjFTdwQ4l8q15C JnYZgolJJxmdQpVWKUZObQcPcDvUgd9SmWTxna5h6SvKEixRVddg6YvmASy3kh1vVDtoCWWP4VRh NiHBxEhhtaO7cS0lfrD/JSvhmmXgvEON0Nho3U4u3SFLI8VZtPVmtOWzQRQ9HUjttgOwjHE9pW71 vME9vKIVm0XkhXgX0OEwAwExSq7b6P6GDmw/WpHayy0TAYkxDQF5ABGdDNGEwdkQS95OPLMVQmMm DgGREkSF/SMT053x9v4+AB8SAoQ1ttnBO0NONhImFd0TmjyerhwmW2EnMHyDcbIAVxOf8bkWgFLk aKOTarNphhEXGQsY4EJdBTqUk2itdjAqCqqgOiU4NbXzQxZGRObzVDmV+D0/P+aZuwQblzPquBgd 3/P0tp48AT4aGGrh9P8qUAU6cgkEFUtlAKlEKsZjUlhxOodP1nNjsSKs/1kLR7ttDi2bE+dUdW6o 0dXZ5GybNu+KnPrmsFh3zh0Pb7srVv4C5wCd1lb48O5a+PagtsaEqsKszLy0hLgO30o2SuZU5gAA HgAoABwACh4KHFwpXh8mJmZpbWNjaXNrJyhIKCZKhCmCHYJnU4N9hXeBgVUmSDJKNEqWdWm1g7mF VVSwVUrEl28nHJgnANRpj9Fpx8cpVKx158U1yGnX1fl9388FA/fOlrte53xF08Zs2MJhw4JVq0ZP Ij0KGqxpMFCgWDFfF30Z0FBsJMaLFwuMRGWCQqcKoGC+ZPmyxExQFViM6WChQ4cLPX/2BAr0gIAD Dw4YEKD0gYAAAioYCP9AAYKBqg8CQAjQlMJRARQMPJBKIcBUAxWwQspShUsWDhXagqkE98SkuZWq 5K0UxgQXNJbAfJlUZYoXFlmgIrEAQcDiIRCsKIb8pEJduEJ2XsBi4ULbzhY2W3krF1MZKJTRUGZT IQ6aOJTbvIbLosMe23ysHHbygPfZszhf5FkUXI/wOx1a1LYiZAvpuKKhi2aeqa2QlhQEFVqjypQB Vee8r4OFjlevZbMI/sNG4hqFa9cOngK4DNhFica2ISy3yxeJCeTWWccWEvIhwRb+yGMGP278a+aX eUhQAZgJrPlGnG8e3AUdUhAiLx953kFHxGDWyYWacgBSR0T+3MPoGnD/wBmnpJM+6ggsj04qacYZ iwHAjet+NAEmmyhAq6MVkFzBp9o6u+AnDnzi4KfOfLrAgqO8quApqsJSigIBHuhKLLGmKiupMrEy gCy4smDOLi82gY4Sv/aKAi+86rJihUjAWCOwIeJizbIw6LSgMCc4GCCJ5SyAyk4jFnNDNCs52ykB Cy5tq63QolvurUNTe2KNQlQbtZBBWHuiuOIa2QKPEyyA1QQ8aH3hhTuCywMG2vLgAIbaeA2Mi7ie 02JYY0EbAIEIlg0tAk8tuE7IT+ZYgyVrX8tOkCIhMCJMCB7wFq0HQHmgAmlbYmmEJP6AgCoKHjDB XHGcuCCGDioQQN8E/zrwYCct/3sxEQ/O1aYEVwJcxYEEibjAAxggYCbBCSr4KdpmGnqGwQklJDAe ZyroaQNaGvQPomcSCrGdAiZgBSEKITqIv5mDqQ8c91i+CBxmeOxoR5N2zPGkAHKC9TArTjjsBFhj 5XNpLfBwkrNKoZTSigMqOEDrA8rUsqqrjrLKy6/KJEssstA0QKoH9mizuk4pqeStYS+r5GhB5z7N CqiEYOxKJe5CVAgkmviiUTMEK9yxyZToWy2rsdAsiwauyILTNsFAXLUznKhLNsoWUWTVVfFo4bCi F0laOBaIM671XG/VbW63uji2C+g2a9uKASq3gHctEKiWNRPaEGWFIv8ROff45LELRINzqZqpSJba aEkAlrBbIzkP/MWg31a3CKonfz0IyskEgiq/AxfWh8FfJ5HjYIVoSJmq4gvQR9+nczUggYPkLuAC EPjrAN0YRn2EkIADDKAnLYhRBuYRsg7wywPoqwA8FlIBD7TAX/3CV4ZKAI0JBAABCYgBB6dkAISc QoMwOGEHwsQOBVUMKMVwgAo/oiAdkqQaFzGJjWw0Ix+BYgRtuAnTYEUGpD0tC0mbAXKqFMUWWEko j9EaUpDyJTFhyVxl0WIAxkKWsIBxKmARCyTYdDvqgGE0YMgDXPpCKEDtTQCMSQJUDgCBA0QAa8HD 49ZO07fAFI4ycqH/zGQKGchAvOUyqomCG0LlSDf9aXM4ccIUnlCXN6TmBKaajSJoxQITNG0MRisD 6zgQOz6sIDi5ohUoWefK5PAqikKpZWa6gAVl7c5yz8pC80ShAUTAoQKiEIUJNIBMQQiTEEhCHhwg UJMHbGuaJVjeBpa3AlCYAAIriGYJwrQGd2lzT66Ckk/4lT8CXGAA6CthCc9HgCrBLwHwRJ+TOrhB D9zrfOhrgMOQU74ElOUp/GJnAryHP/zlDwEYuIAAEIDP86HTJwEAwFNKqCyH5a+iFiXFRyXYL/x5 NAAh2yACPorRBPxKSx8FwFmQgwCPujQAB4hoPp0kUwFE8QAudWlL/7bVknMZMV2GWqIWVCeUKbXA Ao3oTHJQIKWqPYmp+SqS1p6ghZJqiSxiHNNYvlo2NhELE3RrTnNYA6gybKEvUECCoiADAUU9xnBZ TeQg9VZJQkoSEICqTGpY8BfNZdIQQhjEHzD5hjDARq+CC5WpPNkG1eXkCUbYgCJgxzpUanZ1ofSs Z1+QJFPZjnagOasaTasJ1ixTmc1LpvGwwxJRFAmbJphfMbX5CThYc7fFfEkgsJPM4xWjDeQsl7mQ VJMNYOUBqvDpc6Eb3Y+ic6EIWKf+8IecAQBAAO2coD470FOXDuCh5E2AAGiagA72JAHYRahMpevS /02wvejkF/vKh//PnuB3fAD1iXc9wL4l/cQpFzUwdBHQkwrEN74vWYE1fjs9crnnXE7Y5tIwTBsU WOkCU+wACjpwgg6woMMd5skYSsuT5sStCQbYgu5UNZ3TLierKyYNG8/ahNn5JU5WkKsJ5ipIHUeB kXcVDKP09pfGQmGUUMhLnkQ1BCgfQjV3uCSVLdnkzaEKNYGYAhlSc9jNGaFxqx3VBjYQSlfiAXa5 +pwnsLwGIBWpWsVVVYrVWJ3sYLm405sDBTYwzg1gxxOiTaYnbItbZMKhJa8NxHCT9AZR1CQ74OLN VniDCgZvmtM05Un59HUAnoxvSSjUn1NmalGCGgUBWEAAqjvdaQP/jO8tRnEYB3w601jvmte97nRR Qq0vowgb2MM2NrCRHexjozrZy3Z2s5WyFKPUlNpcs3a1sa0UpVhb2tzWtrS/HW5wLwWM5A43tbWN 7Wuvm9rkJne5yRhvqci7LPO2N0HxnW9975vf/e73RVVt4IAPXOD1I3hZAJ5whB+84ASv38MPTNKG TzzgEff1xTGecY1vnOMd9/jHPa41Yo9c2c9WdrOLUhSCJjvZNT35y11eFHGLe936are0n8K1abOb 59k2t7rLLZWe91wp+Ub1vlF9b3ov3d9Nd7pF7/3Sek+djApv+MIHTlCra13VDPf6wx0u8QNbnOE0 hbjZxw5yta+d/+1td/vbNV7slAd77nJ/OQJQPvdVG6XuwXb5sXPulL7PfOfjvra+vq3zoI/73Oye OdC5VnSdS/4pRZfKvJ9CxqMXnYxK9zzVP7/0e4de6VznusD5TXGAez3rqv+62LsOcdifPexjn72u 0Q533e+e9733/a+HjfKSCx+iVyI5slUd7bqrHPnTHna1C094bzul8E8hd8ohD/TGoxvcixd6Waif +fCH//KZp/q7K59+0YOe/euPN9UJivn4r17r8sd3AfDt+rLgH/Vbj/3rCw7sDE72CJDsTqEUWEE+ UKEWXEZBugFFFiI/1oMCUmA/JnCHUiBmHnCHcqgbZmEDjyECI//CQiwkH/6DBCEiItyjIxxEYyxk eb4hIDiQGUhQQr5hHGrQQiKkGiLkHr6hAnPwBoUwCL8hH/LBh3IEaIQmaJjwIkAu1Owu+KTQ2UDj 1V5u2FZPCv8O5QJv2CSP8QzP5ShP5myO57ot+67t+xwPDKUi/OAt/LgG/DjPTDov6dqP9OAvD99P D/kN/+6P3+aN/gDw//pv4QrR9QiQEFOtABfxAFvhompBPryjG0KwG9RhP2ZGBCNQGzLAQZpBGmpm Z8rBEnWoFMtjIZYhQXBwHjTAG4pQhAzIE4kBY2hBBR5sAlYAGNBhFngxHbjhY3wBB0kwIoCwIvIh BluxP6IhGnD/sASA8ASPMSPAQRrtQwmX8Bp5ZCQYrKaSotNGbu6Ojfh+59X6Lvj0DRybD9iUL/Bi jg3PkAypTQwRD/oSDw257/sI7/LcDd7aTfzizSmKzg47z/zcDw/xzf4Qst/kj/5W76WuLhAPbuH8 kOKwrusGsezKrgDTLgFvCAED4BUM4gN9oQHNIUUyMR02sUEwKEPSIUJ0URv8AxtQUkFMEhX/gQZL EDv0gRIjsCF+IRhrZhnG4T+yoTw2MGAuxD1O8EI+pBVjJmYmBGbqoQSGskLmYSLoAUN6iBWRMGhI AglPIgm/ctO4UWtw77mkUOToThyr8ALAEQo3b+WmMB2VLdq2/w3nzHD6nI/byk3w3DEfry/70i3y qA/zKO/oCDLf5rD84u8OHVMxIfMgp87+DvKipELq8g8iEfEiGzL/WM8QxS6lDNDhUsoBAmCEEtA7 XME7EIIjdEiFVmQTSRETN/EhZlIZ4UM/ZvAoIVAGLdBC5mED0UMb3sEnY1IpJ4Q9YoQ4cyFBRvFC mpEH90NCRtE/PmRnKhElf6EeCKQIJWIkJiIjvrIJw1IlekYkACBJYmKbVGBaPMsPjkdIBKF2MgG1 rMBJ8JNStOBZooJMvMrFMMFNRqMtzIBuhoUD8iJvEGWO/iJzMAHNeExu2AIv4iRx7ASvJmEwACUv LgNBPwU2iv/MyaIAkzaBrxYrCsSAQzmUEEIFDUwlNdagNQghVVyDCmz0Rg8Bm2o0RgMBm3rUNVZA R/csCZqHCSpLNbLiSJGLzNylm5LAXIDr0YrrD9ThNE/TEVczO2XSI17mJDdRNm3SEtdDHsoBF0pR h6LyHUiRITBEHDqEZdYBIGTkG6gBgw6oGCykPeC0Q8KhGS/kBjEmI3JTApURHCakBBIkJtUUK1uk hwRVCSGVPIPoJNLTBNrzOlrCmq7DmhZBOJDEUuEgOopFKWTsPuGnSYCHxtBm3tCmMbrgTTqUOTZh WAiDEi5BVjFnrTgUQctgE94IMG6VkhTnkRrJTpRsD+LAAvb/5FDeKJA4oA0GCZOWbJT2pDKcrMue IDb+YAiIic9qlHOwDMtclBD8IDXoDEZ7tFvPpTWIKdDqiAnEyV2ItFuowgj4pknpVZzyhVwgAJv6 NZtsCw6sBTvqZ4TW4UrR4TTFgjyckyfP1EvBdDe1QRzg4xVcU0O0AT3wA0y5ITaF4UPilGVegUNQ kSLcNIS4gRr0oSFaQQbJoQYrAkMmNjg1sT+KYSJO5h38w2SAoSFiEEecMiPE84e80hq9Mj1hIoKo R5iqR5vyIBHkJydE6TCK5ayOAoymg8M44wJOQD/lYivGqCneT8bipGzTaMVmlU3q5sgAI3MkYQwI IzBkB04M/wnJ7CSRUpRqm6wS9gSRIGXJDkWvUuORpKxzBCdV/MCwSEWyUmV4AMEyRAVxu2xUglTM IjdVeJQN0CwOYtQPjCA7zIUqmEAJyMwJuqVbdsOb5kAA4iC2BCEOdguoYBdJVC0STXOEEvYST8E3 Q5ADlZIqNcYmCWQaqDIV4YEqrdIXOMQHi9AWh5El5yNBQvYdvoFDFCZACsAf9IMpIyRgsKEcDtBL 1wMebvA7JOIk0eEhsnIYJgYVnwFG2OEBszEJVUJoxhMbUYEqjwcchGQOQKHRriERAiuUZmUFAGgn 1EhLyKQxpAY/t7YLwMRL0qRMyg217GJCXwwT7uRtAqcSYP/FLuAizbxAEu6kWBlFWAuJxoYsreBo rxolUu7WWhWJyQopVNtqyoiVy+yKeEoFEFAlNmbUzk6FVMC1sJBEVP6AzhiLiM2Fm0aXXU5XDN41 EPIoceMTm1qiPbE4XZ4H0TYAEq1UFlzmSptTYszDFB9iFGcGZWImRj4kYl8EB4+xTXeGRZT3IBYQ JNWBZUrgo87ho7I3ey/RIbIyIwAiQVTIFT7xTPfjY8jDJ22SBnFQGpoBIGKyAotRdx1wJKbxfq8R f8ESABINe1ZQm2xEm7yMBVaAVmaFNjwMxJBlMchm2EzVJx54CJziq8S2S8qiVAVjbjQFc9yiQ/9k NGLVQeH/Yk/Mqpzypi/21k0sdA4Coy++TIYDg3CySo+uZAq2dXPeYlQsoK3mJHG44A8gd69G5Q/U 9XKBuIfRING0g7Fg93O8lbZ0mMuc2Ei7xZtKqm8/13TfuTXcY1sOKztqoiXi4KKyFxVawRRiQTWb qxcYlhso2mAYeSGisgV/YVDnIyaHVxhr0Bry4yPiAV7YIUC0IUCci0NENk5bRk0/tnlNEh1cgSMG ImNvk3znAaY3FhlokNAwSEP84xm1khZO0zmPkDyL9pORcIj8dwUHmsKahyX6QJVZYAZKB4Bow2Kg w6rqKNpqamudBAWWoyyw4kvGgoKpwoKh4C1QTDqeoEhm/1U6GCVvGNRT1HaDLSltKWmQLrQJXsOY lbUtSJcJiDWvTsMMtNVwjJmRMAFaG6kJZiVbOaGx6JkyKjdy/8BaqIyHU6PM2FnO8JmI54ADPhcq 1oAFQFtxOSfReMvClEdanAD/dLcVPnISBWQ8uMEWzFSHKlYGd1aNfxJ6SSZDHoQEdvAYV5E4fRMe KuSlFfmlSWQVsHcfzkFkb3IXSnBQ4QN8e7cbMpp8l/OQKSC6v/tPi4E92INkosE/YgQftnKTyxOI fAaUzRMVpOU91nO4AsG2SoBWsHpqK0V8lkQLZlkrikIsoAI/yRogzxpsxwhtKOCE6TNEteTyikRu 7Loy/v+aEthEydjCLu7AQe/CkAipx3BiXO/CXvWocaB2r9CoWo9MVnXsNBIhNZ71rsR5DlLUcX10 nSvpdcsAWzjHWtq1nQ2Bh5UY0cKVsCyJm4fAT5pAxqVVsZNpXS21sgsBdl9KFlQkFsZDPY6Bt5sb j+3YHWiTQT5xQVjkQYoxT2VyRYzSFeXBFzdEkBUGTlWmQ9IBOKNBTVUBYYxXzenjQchBREJkGURW KJVbjWEGRryzKXuIHjjCRiCoI9Skfj2ZaMeyWt7DJhxs0LJ4oJOmgHMiP6WEigq8UUi1pL7CKapi wWHlanWZVcFILIR5Oc6kS77qLIDVUFQrUB4UOho7r0P/fC7oggv85ISHjFHS7K8eIwK6JY/ySFGy hq9oOJAGIZa/AA3oxJL0agoot7VzHBAiKVs8iVYad4iD1HFVQ52JWA7SOVUARcsSacn0KnFngnoG TVtNAP+ytxVut6EngDUjejjJvIx90Xt5Yc+Fsh3KvBn6Jzih80x5uhRJULljBMxJYUNSoUS+A6MF YgfpYUSYQWHy40Awnih3kR0iOhv44UX0AR4G3RukUR5gxEU0naIp4NI/Qk3u1yQopCN8JFNBPWmx R0iop5VZOT9VnUmgxAtCDSm0xGuKbgjCNvK2gmuwYipEDTG0xIvURE3ESi4uoS1Q7FgmaUIvwQza fjm+/6wNiqxBC2c0CvTKdKMJlAAqVjuy9eqR4qaucVXE2aQNCuMS0lk2LrvJ4/kMECGUGGmz1314 5IDO4F0O7nk0PMuxZ5w5grVwqmd4kGfQsnWEVIQVxlg9rLsXe/sghkEEbLY+dFEXUmRFdncbDrUZ 4HtnRBJjJxAYUuAGjZAieFKlP74dVPMTo4EChdEW3kNDarpjCXUXKrB3k8EYotsVd9IBHUQpJ14r dZ4efkhNOEIlLp0kgH5+wxIVZIJ6igQmriHpa8J/RekETGAMqIirhwJVhQ0IKoEDJFA8PARDISXw CBiKzYch0DxUiAZqoMutbisVy9hiJls4p3OFY9mYx//wNtn9Jo/lbE5evRHP8ZHN3Y2ZcLBYsFQI QAwwQlRAWEyORYqhiYmZaGaemSF8io65tZng5R1WnFRwmmycwqJqav5V2HK2arLw8rrx3r62rlQQ RxJzUtAKt8IWK7IgtnC0JL7loWVnkyrSqWmWiKncNiubrABQABQ4FDxMPLhPULTTTzhQwNvn58/j 48MjQUHghBLzVNybl/CeAQcAJ0Ds168EBRUUDKpQ8XCfQogkJghMUVGFhhIkVazg5wBixwkA7uF7 CXElRIsoVZhMCbGEhowGO7YD8HIlUXs7Wb6Dx3JmP5wD+XXMZzMfRYQkSmIlmZWCBgpeKRSgkIGC gXn/XL927XpWrVcNAMJRLGGCgglOJVbMrUBXrhi6anp1QNDhQgIOHTpYGNyBw4XGAQQIEQLZiBED AqpwofKEghIuTaBk3oLZQBMDZQjZqWNHD59SaVKXKVQHT50ytjkcinVNkKAVZKw1kkSrQqhLEVCh cYbnVGwzdlJ/il1KkKZXmZAVaxZrOC1im5yJQRTNl6801YfX5X5rxYpevqa9j4aNUHM4nlZry5RL GV5nr9KtA4ADZb3zTz4PvZNgPu/swyBNUFF0ET0PzsRSP1F9ZJCEJYi01FBQKTRQRgcCdFI/DylE YYUv0VORQib9tBNOPfFEAkD0yIQjRAKyVIJMMhG1/5RLFKRAUYgERVRQiCBpMMGMJmFVUZRmlUUa W2K1ddZaaKmjTFx62WXCXXpVEA6YeOFlhgkXDGZYmxcwZphhF1ASRRQBMPLAAQJQcIATftoJARZ4 EirEFo9RwSdmUJhmBhyCZLPBInG0lsl0cZxB3xrZ+EYbbW3MNyltj25zSSS0nTpcJifMccoZjDl3 AQLQQeccqI7q8QcxxLBqwiLgYafeJru4x0s1sK7BSiTKAEJmMSy80Eu04sHASwfjyWceGrVW+gkh ZwhgAWSOvvFKLq+UAEsBAbDzUgADrtRiPfEauFJSD3hFrz/8UFUQVOo8iM9H/ZBgUkYWzYOkS0wB RP8QTwgtTNMEJSF8z4kXLnSgxRcpqcFHL+I0lU0attQOTURBSU9YDrHDUpA7/ZtkgUvmk0EJD/PE U1cmWkRaWGFxZRZbahHNZTp2wSXmXEuDGc5cFJV5iBuNJYbYYlZfPZgFfxqBhJ+RRUHE13geYNpl pUHRxaFWdAEFN3DYhyl9g5B72hsnXLoKNnuzYWsdqnAA9yq7HYLHJGSEW0nis4hbQQR5YOJbAhZM bsEFDFiAAJyZi/IcGsS8Icgi2jWDnrB4nadLL+IlssYYrpPxQBaAQBstLy8gYns0L8A3HiLbvKqt G6nxJorxkZq7QbrhoKMOO/GoM0EA+67U0L4QJSj/84HbE/SUQRT9w6NKTxFpZEUrDZWQxtYnaZJL 60g8j0kXvmyPQANHpeRTIHmVMEZSmm8n3WNJOpx0s4pEz2TysNjCDqI+euXILN+TEVYetrMKkOQr YNngxLhStKFpqSsAKBNdLnIzuXipaa24C3vqQpE1JIBNiplT1q5GJwtogU9f69MQJnOAPkWmC6VB ghPStjY8YcM80KED5IAXm1uk4Q6Y0ptrkhMp5AxnUuRgFaswgY1UTaISh7uEF/lQATpNLhShQAxj BGM8UtXGUrmpwCK806zSLYM7roCFNDjAul5YwDfPScTuOPAC3EHLF4hEhHg4AAM/RjFTkYzi8CZJ /8njmWEAoOBGdlYAi7mwJ5SiHKUoOQEBvoyALhUQwQpGUBcXKu0ceJElLV3RCk6gRAaijJGECNKG FngAAf2zmGEs4KKg6CsfAsmgFTLGP/z9hCrKfIpABqKhgVCMYwlTRgfigsD7UVMj7IAX9hKSI/dd KB85otDDbIKQtlgkS1+Zx8+2lCUQ3nOEFEmlCy+ytLzYMj25YE8HWqCYw1hNhgjVmtb2ZBrLcMYy jOAMENnGtiZQ4AmaqUJGIeONS8ZxNnsTHRM3gDdPWGpvoKLDo8LTCjJAgDp44JUtCGkJmApHOJTg m31umMYbcg6ooQheHLwYOVosYhHm4gB27Nid6v+cAC++890v4POb9jDykOPRqiNZMA1GfnUaqsGU c4JXyU+kBgHHydxxhqpG2+yKArDYlQZMoIEVjGMcy9uACjiBlwfIzpSygwAEKHAJ2YXjAaibCwTy gq/Hyk52Y/BADDwwDXUAwADU4MABAFDNFTgSoY3RnOVIKCChCMUBLLKc5gZDGAEwhDASSEAM9QKS hPnrJ99rkgqqSYIRzSMxHuhmQRympNu2RUPtYgeJklQRI/2EQUNi50gopoF4mW+ebUlLWrR0Ty59 JQDs0cUJclFeC5zgBNZIlhlYoN70nsBqKBDtQdtUCjEM6oeXERSeBKBDPXkGT6KxghK2UJpIeI7/ kn04jTX4JrfZkLWskojDI2AaR1rYhziqwKLeMhGJx+1UVSE2Hp1aqzlZHW+JmHIDc7pBC1bkQj3Y Yh0j/1jjqSbid+pFb1b/qLtoLYaqeyBq50CKSQtoUq2cY+tQzeBJE6CEP52kQEpWkC5QUnlXxUCd GAabl0uYQLwBuEtfuywJZUj2AjHowHA94GZgdsAFCAiAUATAAct2IAHDxcBh2DTcMkGtoAJArQMO QBg2u0AxB7RcnhtjWdta6EhPyRwBWqC8+xVkBQa9gAfoNJHjpqvTjr7swFQQj4V04TAuaMGaEVCB pegpzjDowKuxmxHrIoS57wyRBjXQ3Sv9OoRc/xmhr9CL3vSaIVnuNbY1jL2KNcWXTZuW4ezKBgED D6oCEh3Ctfmkw9J4hjRK8EoXkKCMB9uKD4tQt7a0gQ07wC2KsUEABAQQgXBF4BGRICwk6EjWkWZC DqoSQyUs4UUQXyJT5Hj3GSoHVKLyzRDLEYN3Yswdp9IRx4wczxkAmQb1ssBXiyRPIg2ZyBn/zo/R GB4kaXXJBJ8BAZpk65LVGAe5nuMVF8FgMUA5JryoYK6ghHLUJAEByUqW4FbG6zlK0FgLrPrPuqia C6rO5sO0mc0XGIB/GxNDhLqAA1IZRwW+7vUEFNQDESAYlQfTado2pgMmsNAA4H4BAugZBi64gP+G MlSBPjua1pH2FwvoK6thgvrOcZchDKoxGLQn+rIY84dgYLBmvZBMIk2KmQaF5t2x/NrXZyH2V3yF 7NMj+xPKBiSd4MQmFsT9MDgUwg/xRFEfdjui2r4o20gDBcOCgQqcNKs3QJU3chWP3Sh13AEeB5kI 7FsSj4sEFjzRiSd2Ag+jI/invEiGx4GYEOBBBTH+8IcjT7H7ZGBFIIcFCIunoqYax1YZ3KOINWDV PYbcOAs2gEjbAeC0FB41FFR9KZTh0VcmKWAozNySkcE/2QUGOcOumEl/AF0obVlKxJhinVlKFMNd 3MU5VMADgBIErEBkcQI1wNmhDQYCnJgMydD/cHXAmg0X3L0dbdWdn8HZcLEJBsTQD2ZdCHgdYQyA YHRAZ6FWEgLAAfzgBTTA1QVGEtoZm3xdDNGZEgpFACBU1oFAol1hAODZQgkBahlAQfmJEj5GDP3Z F6IdniEAFsJhHMJhzy2NV8jFe6FXs50BfOFBY0ibYrRAYrQAm1QNrWVBn/QJgHmNnvweaPwQI9oJ aYQGF4QH8hlfEjWHbJSBG2RYHKQKGTyC44ji9EHGnnyKu3VfxHmKiF3f9eXC6MQYH7Cf+7WCGQ2c GGyfBcAfLpKDLejCH8TYKxRLsfjbe+HN7iAStpDc/kVLeyRjItlOC7TAfC0Um2wOkWHSzBVh/8yR gZbNEs95xzjY1TnQxV1BGXsEXc7xVTFsAJWVCc9F2dJh4AmqQGG54zuaRDDghY/IYRbS2QBoHULR lg1qHWGgHW35F9rl2UAOQA7SFt4plDXGXQI0JNf5IQEkpETWINbJCt7pWZ7JXA/G0AVgAGFcIQA8 BkceBp91AEoKwHC5AAiwQGtxGptxwEmO0GJ0ARYeANZpHUtCIdz94ABkIRImIaDdkoQ8gFy8wo6p XnpFA7L5oeVI5CBSjTUqRlF5xWXgCxLRgmlYAUeJxrVlVNlslJ4w0YUV1fBhwjdUEm7ARgUMwCSE CxZEQPM1n0e1gRk5kfdZn/Wp1OHQwix0wv+knAtuuJT56c1wsMJKxRh4bJ8u8GJ25IIvVhx4aAKY jY57URUHfEDJuUd7SIt7RIukzAALnOYMpCYvpJglmUGJgYK4pIHMOSAumUt29FU42maZsMdd3NV4 7coGWNkf5KZerUBJ8CZK9KaVJY1XfCDPARa+VEA/UidP9plQ1qRPBlNDCkbWGeSoDRdENqGshIub HEYLuAAMKMB3EoZBtg1KKmFPuhnc8ZmfwYAHfB0UQqGfyVCiyaBAEkBN/ucRopZ/GYac4WQX/F2i XYBRxmEdigm+1MXOuQJ7RSV8pdcFzNcgBqJrdQAKXADscagM2cFiUMcmUhKzQNSKBtgWmOX/gM3H fbybg22LEm0LEVCCbErCXNKGLXoKYE6RUQXpKX7KiUamUdXiZHqRxQ3CcNhiea2CLxqVd2CcJlwm thAmGdGRVo2m/t0OybmHep3mQFWmqpwVNsbmrBzPcy7WB8YVBg1dXaFEuozDeM2VrhAnPGIQleVm XeGFXMFFzwEWV6ALY2FWdSIqFg4AnVFkG+7gYexeFjYk2jUGAWiOQqZNYshK3SXASeLJFmqdDOLQ oMnhAWxaAuBdnx1GDClABwxAgEKhB9ynSrZg2whAdzZeYGTBe8ohTiYqnOYcXYiJKoXJLqyee/nh BcRXtH1o3MXXfM1XWb0GnSCGWW0NHeCB/35lAVqeomkwgR6gaPHEaB/cjX20lCW42iPM3Ow42aqo okoFnPrZBofVwgMGA1wKC3PQIuTkAejoii5qQhfVgvvhAhxg1WM25ixEX4yJpjIOo6TwAsadS3ZQ bHWwByyAR1qhVSS5HJncIzKAkl6YgzuOSV/V6TkI5zjSlcqGQ15RhCypkl5VgAboxRMU0aCWUKLq rBz+3ePd3UK1mTSGwKoKQBtaABneGUL5qhoihq/a6gEcgAW0QAgYlK+iVtKWJBEiwH/GHQIQwNFm IQIY1HTW2U7u7NnCYZSJSV+YwCkRqyqlUGJJyMYeWa1Iq2vWKBJg61tSEqS0FMdqAydeUqEe/G0U wUEikMJKBZxr8GuEpV+HXV+8el8TccdvEO71RSYnPKC9Tt3kDiwULRzGPsMujEH5xVj7vZ8p5RSZ oof5sccw6g5qPlnFtYI5AAKX2RXFfYcmnKnL3RwJDZ1eIIMGFgPO8UWWzQVdPFlFsAeVFaryxFWw YlAptZAoSYIA2OwDoO32xmEZcoAUCgCnOYd+5pmlWi33bi+eoO/6sm8QAAA7 --Boundary_(ID_itkMQiOPwLT1/vPNMumIqg) Content-id: <000701c291df$5a4e2340$47904c0a@huawei.com.cn> Content-type: image/jpeg; name="=?gb2312?B?19TIu7GzvrAuanBn?=" Content-transfer-encoding: base64 Content-disposition: attachment; filename="=?gb2312?B?19TIu7GzvrAuanBn?=" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEAYABgAAD/7QY8UGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAAYAAAAAEA AQBgAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB AAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA MgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////// //////////////////8D6AAAAAD/////////////////////////////A+gAAAAA//////////// /////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQIAAAAAAAQ AAAAAQAAAkAAAAJAAAAAADhCSU0ECQAAAAAEywAAAAEAAACAAAAAYAAAAYAAAJAAAAAErwAYAAH/ 2P/gABBKRklGAAECAQBIAEgAAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0 LjAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwM DAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAYACAAwEiAAIRAQMR Af/dAAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAA AQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVS wWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSl tcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFR YXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOE w9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A 9LDTMd04rKK3lThG1ggEQrUw2FIkDlRNjfiha6gF0kg4FOkpiUx1TkhMSEUMDWPgo+l5qcpSkjRT WhuimIQ5SlJVpZCYuChKSVJtdxJQy1ymkkgi3//Q9RbyFMmBKYDVJ/0SkgbI3OLgZ+5RT9lEnukg lcOgyp7pEhBJTtcI1KKLZkpKJeAobjJg6FJFpEkOToe4Sk8+PKSrSJ0MSNEi5wiSkpInUWuMweOJ U2w4SEkrJKUJQkqn/9H1SEjqIPCSg7yMFJCN2hhQJ0T2l0a/IhAc5x0OiKwlkXjsma4nTkKHPCky ZSWs04SHwUg0FJKwHgpAJwD8U8SkuAWjxUXjgKeoTP1A7eSCqRifgiMsgweCdVDjX705GqSmyIcJ HBTwgUvgweOwVhJcH//S9UPCC46yjO4KrkyiFslnQeUNwjQ6qadFjQFnhonY1wdCnsIGpTgcd0FU oAqQBTgJSgvpUlKQmJKb4pKtnu+aZ4BHwUdFKDGhhJVsPxCQ4+CbX4ppI18EFJK/pI9ZPHggVlsn XngI1fJRXB//0/U7DDVXHKsPEhV+CiFk91OEFIIgAcIKXpoo4VgFL0+/CdohSQXAIUxRHubED8EF 8/moIKimUHbhzKbc4d0lqQFSBKg1wPx7hTCSQs9p5HzUIJRgkGNnjVJcxqrDwQR8PgrDWhogJNaA 0acKSSX/1PUHvgIRdKcukFQTgxSKRhRQZQGorUCuiWai5v7v3KSSS5CmPwRXNB17oTgRyEFpYOAJ 118lAt00MnwRCmKKGLGO3jjzKIAYB8eEqmncTMfBGCSQGAYdR4aojGRqU4ToLlEpiUxKG5yKCX// 2QA4QklNBAYAAAAAAAcABAEBAAEBAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9w qCA0LjAA/+4AIUFkb2JlAGQAAAAAAQMAEAMCAwYAAAAAAAAAAAAAAAD/2wCEAAYEBAQFBAYFBQYJ BgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBBwcH DQwNGBAQGBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDP/CABEIAJYAyAMBEQACEQEDEQH/xACOAAADAQEBAAAAAAAAAAAAAAABAgMABAgBAQEBAQEA AAAAAAAAAAAAAAABAgMEEAACAgEEAgICAgMAAAAAAAAAARECAxAgIRIwMUATUDJBImAjBBEAAQMD AwQCAQUBAAAAAAAAAQARIRAxQSBRYTCBkQJxEkChscEiQtESAQAAAAAAAAAAAAAAAAAAAID/2gAM AwEBAhEDEQAAAPTXk0aw+pTR9xqIAAgSzicihL2tY+hrCwmLPKeFNq7EOowawDAhYEuBACY1ENCB GACG0puNWFEkMr1gQsCBKARjGjUQBCasYr0hqcQkBisri5ogQDGMYJjGohMatVdzVzZgBCxotNaB ACAFYIQ1ghNWMNqU0U5pBCwIXNpK4hNBGogDWFK1a1qJjJTQ0pzZiQM2eSwQmMGsNRNWs54dKW9e q5jU1YWI5QyTKMJmGrLqNNTGsNGsQkFEc7daeiYERyllzYShJANXRa1NWprGt1mNUMzGAVru1omp co86sc2ZGEgIa6bW0Nj0awawKhmY1Y0dm7e3E8I8qsLEhEAidG61ho0DRqI1TkmCmMdVtrXqPOx5 BACRNYafUbTAgQpg1qUkhBVi9t7Xrn42eCxghoaCw6hoQIWNKA2GjUEUUpV7ezVY5eFTNaxMiPo+ x1ERRYXISgBhrDopFAX1e/VY0cvGzxbdIIENo+pTRScQzIZCFGKWtYdGoGOvVcwIli8/JTau41AJ qQjmLCRDJYBSr6Gm0aqF7cAnix5kzTZbopqGiIQkELAhJVSUNXRa2o9NV7cCBEedlirDFOkruNox hCGYkCFBKBq67TqPRrAhMlzY8yyiGqm5TZ9xjAEiGZOBKDFavqvY1atCQmLPL//aAAgBAgABBQAg gVRIXjS2tjYxnUVSCCCCPFJJJI3sjRbJJ8E+RaTskkkn4C3ST8JD2ST8CNr0nWSfBHjZOk+GNkb2 MbHtWkEEeFbGNj+Itbb4+AtLvfAvKtFpcW2CN86LatWWENaoSI8y2WWiHUgSFsZJO+CBbLaLSCNZ 0ZGxeGRskTF4HpBHhkkeiExbX4ELY2To9EIW571sYxn/2gAIAQMAAQUA/Lz/AIzOyfyE/KX45+Bf JX45fBn8pHyV8leH/9oACAEBAAEFAOSBVYqFalULYx+rY0y2Kx9dxYbMrTqkhaSh2LWLNjHjU1xq FjQqI6IhEDWrWzjTsdjudx21hDrXSi40+yo86K5pckkobRKG1pJJPip+pfKk8jbspRJiyMdh2Gyd y2LZBX9buK+3bljJ5raat6SplCsm3dJ2vWr7VhOsKyekbYF6y/oN82fMppsx2Sq7cfbUtZu02G2x t2EpF7hxVyVyW7dl2gggggXq6mr4H6bJL3itMqa7WQ+SHECbIhxDiT+Oa2V7J1yKa2rZwQQQNpKU ZqjZayVb3Y7NlVVuEcoTQkQdWhQJDTiynR+8Wa+N4r96QRoy9ObXypXbq73dlEqGirt2TFB1FUTa FDTqcolMaizUOJr/ABgs65K2VlpdwO3LZejQ8VWOtqtMo1KgSQuBEECtoyzsmnKrwyst47dXM6ZR +2y1VYvVKzrI8VWfX/sVRVOqOqOTtY7iskTJlSmJOzQ2UT7GFvoZXy2SSJF63tZ1shptKBEjbHZn 9mQQQZO6Xax2TVbQ8Ks7sw/oZnyh+9Eh4m7dWhLV7UWTdWmhtDhmP7bPHkva2OrrV+sjl193rxpV CR9aZkpWr4HA3y2Ns5E2cnJkx9jk6s/5Kt2pjrXRmSvK915VsYqNCRVCOlZzKbZGq1eSzbvc+26K 5ZIJFo8VWLDRGPHRU0bMik9OlhMhHU9H2Um+VjaZasn10Mi/tAzFkbEhCQjFRWZJI7F8nLtJVlWJ 6IyU7JpobY5JP61Hiq30s74sWT7lSzuqtuuNu1cTZWta6NjsOxf9hFGLZeisWq6nJEjSGkODA79k lNKpCSQhjY2OxyP2IqIWy8dbKmj04P8AniUL1raRyW7H/9oACAECAgY/AG3/AP/aAAgBAwIGPwBt /wD/2gAIAQEBBj8A6myhWoAOjFvyLafZ4+t1AUwo/DFGElOc3U0Y+SfwwiafIU3FIQLvzVsrlEZC AOcoPlO8J3UY6ARh6fon81n27J1KJGLeEPZ3K+2U5ui/hciafUmclAmwjsh65M6yAtmoFFCGk5Ra n7qFNt06dfsmynGVKfIKYF863HwaOYZEdlvwntzTdSuKR4TWKZRfC23C5CBRID/KBNzpJ9SyYh1/ XwuAuQnGUG7KRWLqax4KYwVxlPR0CMfynGpzI3UQuHZM10AZ41QmPmnKLymTYNkQgBlcG+qUwEMt 2WyAxzS2mQoMUcBlyp7FP5TDe9J1kgfCYmRdWnFLK1bst6RCgxtS3ZN/kpxAFz8L5TtfoEjKY9Jh +tOVEFA+rgi7f8Te3q3NkxvocaXKYKehdPlNQvDsx8p876WUaXIlDAUXUYV7K78pjd4pFGyuVuvU NselZwmdf180bFG5T+VOF9T2NI81L2GltfOiygJ3RDMB/pACwMlfUSUwuvr57L24UZv1XacJjpuo 9fs3akJ9/wAAvZFjGBOk79H/2Q== --Boundary_(ID_itkMQiOPwLT1/vPNMumIqg)-- --Boundary_(ID_7eKuDHyZ3m/5ZCy7eKse1g) Content-type: text/x-vcard; name="Li Tianbin.vcf" Content-transfer-encoding: 7BIT Content-disposition: attachment; filename="Li Tianbin.vcf" Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT BEGIN:VCARD VERSION:2.1 N:Li;Tianbin FN:Li Tianbin NICKNAME:Leo ORG:Huawei Technologies Co., Ltd. TEL;WORK;VOICE:+86-755-28789558 TEL;HOME;VOICE:0755-28097616 ADR;HOME:;;;Shenzhen;Guangdong;518129;China LABEL;HOME;ENCODING=QUOTED-PRINTABLE:Shenzhen, Guangdong 518129=0D=0AChina EMAIL;PREF;INTERNET:litianbin@huawei.com REV:20021122T042639Z END:VCARD --Boundary_(ID_7eKuDHyZ3m/5ZCy7eKse1g)-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sun Nov 24 06:15:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25175 for ; Sun, 24 Nov 2002 06:15:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAOBHwq23557 for enum-archive@odin.ietf.org; Sun, 24 Nov 2002 06:17:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAOBHhv23550; Sun, 24 Nov 2002 06:17:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAOBF1v23517 for ; Sun, 24 Nov 2002 06:15:01 -0500 Received: from ams-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25137 for ; Sun, 24 Nov 2002 06:12:19 -0500 (EST) Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAOBDPQv015308; Sun, 24 Nov 2002 12:13:40 +0100 (MET) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 24 Nov 2002 12:14:43 +0100 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 24 Nov 2002 12:14:42 +0100 Date: Sun, 24 Nov 2002 12:14:42 +0100 Subject: Re: [Enum] Conclusion of the ENUM meeting (re 2916bis) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: enum@ietf.org To: Eric Brunner-Williams in Portland Maine From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <200211181928.gAIJSaq4004421@nic-naa.net> Message-Id: X-Mailer: Apple Mail (2.548) X-OriginalArrivalTime: 24 Nov 2002 11:14:43.0137 (UTC) FILETIME=[B04D3B10:01C293AA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAOBFVv23521 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On måndag, nov 18, 2002, at 20:28 Europe/Stockholm, Eric Brunner-Williams in Portland Maine wrote: >> ... "A:B" and "C:D" (!=>) "A:D" > > I missed the case against transitive closure. What is it? It is pure conservatism. If one register type foo, with subtype bar, that doesn't implicitly say subtype bar is ok to have as subtype for type baz. If baz:bar is ok, it is very easy to add a registration for it, so the implicit rule is not needed. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sun Nov 24 06:20:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25234 for ; Sun, 24 Nov 2002 06:20:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAOBN3523692 for enum-archive@odin.ietf.org; Sun, 24 Nov 2002 06:23:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAOBN3v23687; Sun, 24 Nov 2002 06:23:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAOBMqv23668 for ; Sun, 24 Nov 2002 06:22:52 -0500 Received: from ams-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25231 for ; Sun, 24 Nov 2002 06:20:09 -0500 (EST) Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAOBLPs4016404; Sun, 24 Nov 2002 12:21:26 +0100 (MET) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 24 Nov 2002 12:22:44 +0100 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 24 Nov 2002 12:22:43 +0100 Date: Sun, 24 Nov 2002 12:22:44 +0100 Subject: Re: [Enum] Help - A question about ENUM Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: enum@ietf.org To: Li Tianbin From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <000d01c291df$5ee389e0$47904c0a@huawei.com.cn> Message-Id: <0DB135F9-FF9F-11D6-A024-0003934B2128@cisco.com> X-Mailer: Apple Mail (2.548) X-OriginalArrivalTime: 24 Nov 2002 11:22:44.0066 (UTC) FILETIME=[CEF52C20:01C293AB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAOBMqv23669 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On fredag, nov 22, 2002, at 05:26 Europe/Stockholm, Li Tianbin wrote: > Could you help me with the full name of ENUM? Someone said it is > Telephone NUmbering Mapping, someone said Telephone Number URI > Mapping, some one said Electronic Numbering Mapping, and someone said > E.164 Number URI Mapping. >   > I think E.164 Number URI Mapping is better. >   > I searched from your Website, but cannot find the answer. >   > I'll be appreciated to your help and reply. To be honest, the word ENUM didn't come out as an acronym. It is a "short word, easy to pronounce in English". Afterwards explanations has been added. The full name of the working group in the IETF is "Telephone Number Mappning". The full name of the protocol is "The E.164 to URI DDDS Application (ENUM)". In presentations I do, I say "Telephone number mappning". Regards, Patrik _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sun Nov 24 06:23:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25290 for ; Sun, 24 Nov 2002 06:23:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAOBQ3r23768 for enum-archive@odin.ietf.org; Sun, 24 Nov 2002 06:26:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAOBQ3v23763; Sun, 24 Nov 2002 06:26:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAOBPDv23743 for ; Sun, 24 Nov 2002 06:25:13 -0500 Received: from ams-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25275 for ; Sun, 24 Nov 2002 06:22:29 -0500 (EST) Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAOBNpb8016598 for ; Sun, 24 Nov 2002 12:23:51 +0100 (MET) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 24 Nov 2002 12:25:09 +0100 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 24 Nov 2002 12:25:08 +0100 Date: Sun, 24 Nov 2002 12:25:10 +0100 Mime-Version: 1.0 (Apple Message framework v548) Content-Type: text/plain; charset=US-ASCII; format=flowed From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: enum@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <6485949B-FF9F-11D6-A024-0003934B2128@cisco.com> X-Mailer: Apple Mail (2.548) X-OriginalArrivalTime: 24 Nov 2002 11:25:09.0192 (UTC) FILETIME=[2575A480:01C293AC] Content-Transfer-Encoding: 7bit Subject: [Enum] New version of rfc2916bis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please check this carefully. There is one section missing, changes since RFC 2916, which I need to add. Changes since previous version: (a) Grammar cleaned up (b) References cleaned up (1st try) and split into normative and non-normative (e) Only one example still in the document, and one h323 URI is added As usual, proposed changes with constructive comments (so I can do cut and paste) are appreciated. paf ENUM P. Faltstrom Internet-Draft Cisco Systems Inc Expires: May 25, 2003 M. Mealling VeriSign November 24, 2002 The E.164 to URI DDDS Application (ENUM) draft-ietf-enum-rfc2916bis-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 25, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. Faltstrom & Mealling Expires May 25, 2003 [Page 1] Internet-Draft ENUM November 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Use for these mechanisms for private dialing plans . . . . . 3 1.3 Application of local policy . . . . . . . . . . . . . . . . 3 2. The ENUM Application Specifications . . . . . . . . . . . . 4 2.1 Application Unique String . . . . . . . . . . . . . . . . . 4 2.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 4 2.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 4 2.4.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4.2 Services Parameters . . . . . . . . . . . . . . . . . . . . 6 3. Registration mechanism for Enumservices . . . . . . . . . . 7 3.1 Registration Requirements . . . . . . . . . . . . . . . . . 7 3.1.1 Functionality Requirement . . . . . . . . . . . . . . . . . 7 3.1.2 Naming requirement . . . . . . . . . . . . . . . . . . . . . 7 3.1.3 Security requirement . . . . . . . . . . . . . . . . . . . . 7 3.1.4 Publication Requirements . . . . . . . . . . . . . . . . . . 8 3.2 Registration procedure . . . . . . . . . . . . . . . . . . . 8 3.2.1 IANA Registration . . . . . . . . . . . . . . . . . . . . . 8 3.2.2 Registration Template . . . . . . . . . . . . . . . . . . . 9 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 Normative References . . . . . . . . . . . . . . . . . . . . 14 Non-normative references . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 Full Copyright Statement . . . . . . . . . . . . . . . . . . 16 Faltstrom & Mealling Expires May 25, 2003 [Page 2] Internet-Draft ENUM November 2002 1. Introduction Through transformation of E.164 [4] numbers into DNS names and the use of existing DNS services like delegation through NS records and NAPTR records, one can look up what services are available for a specific domain name in a decentralized way with distributed management of the different levels in the lookup process. The domain "e164.arpa" is being populated in order to provide the infrastructure in DNS for storage of E.164 numbers. In order to facilitate distributed operations, this domain is divided into subdomains. Holders of E.164 numbers which want to be listed in DNS should contact the appropriate zone administrator in order to be listed, by examining the SOA resource record associated with the zone, just like in normal DNS operations. Of course, as with other domains, policies for such listings will be controlled on a subdomain basis and may differ in different parts of the world. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. All capitalized terms are taken from the vocabulary found in the DDDS algorithm specification found in RFC 3403 [1]. 1.2 Use for these mechanisms for private dialing plans This document specifies how "ENUM" works, that is how to handle numbers allocated according to the ITU-T standard E.164. But, a similar mechanism can be used also for other numbers, such as private dialing plans. To implement that (a) a different domain, well-known for all parties using the same dialing plan, SHOULD be selected and (b) the application unique string (see section 3.1 below) SHOULD be the full number as specified but without the leading '+'. 1.3 Application of local policy The priority field in the NAPTR is a request from the holder of the E.164 in what order the records are to be used. It is to be noted that the party looking up the records MAY apply a local policy for in what order the records are to be used based on a combination of the service fields and URI schemes. Faltstrom & Mealling Expires May 25, 2003 [Page 3] Internet-Draft ENUM November 2002 2. The ENUM Application Specifications This template defines the ENUM DDDS Application according to the rules and requirements found in [1]. The DDDS database used by this Application is found in [2] which is the document that defines the NAPTR DNS Resource Record type. 2.1 Application Unique String The Application Unique String 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 "+1-770-923-9595". To ensure that no syntactic sugar is allowed into the AUS, all non- digits except for "+" are removed, yielding "+17709239595". 2.2 First Well Known Rule The First Well Known Rule for this Application is the identity rule. The output of this rule is the same as the input. This is because the E.164 namespace and this Applications databases 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. Take the previous example, the AUS is "+17709239595". Applying the First Well Known Rule produces the exact same string, "+17709239595". 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 RFC2396 [3]. 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" (RFC 3403) [2] 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 output of the First Well Known Rule for the ENUM Application is the E.164 number minus all non-digit characters except for the +. In order to convert this to a unique key in this Database the string is converted into a domain-name according to this algorithm: Faltstrom & Mealling Expires May 25, 2003 [Page 4] Internet-Draft ENUM November 2002 1. Remove all characters with the exception of the digits. For example, the First Well Known Rule produced the Key "+4689761234". This step would simply remove the leading "+", producing "4689761234". 2. Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4 3. Reverse the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4 4. Append the string ".e164.arpa" to the end. Example: 4.3.2.1.6.7.9.8.6.4.e164.arpa This domain-name is used to request NAPTR records which may contain the end result or, if the flags field is blank, produces new keys in the form of domain-names from the DNS. 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 3404 for more information on NAPTR records and the Additional Information section of a DNS response packet. 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 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 [3]. 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). Faltstrom & Mealling Expires May 25, 2003 [Page 5] Internet-Draft ENUM November 2002 2.4.2 Services Parameters Service Parameters for this Application take the following form and are found in the Service field of the NAPTR record. service_field = "E2U" 1*(enumservice) enumservice = "+" type 0*(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 1 or more or more Enumservices which indicate what class of functionality a given end point offers. Each Enumservice is indicated by an initial '+' character. 2.4.2.1 ENUM Services An enumservice MUST be registered with the IANA via a description in an RFC. Enumservices specifications contain the functional specification (i.e. what it can be used for), the valid protocols, and the URI schemes that may be returned. Note that there is no implicit mapping between the textual string "type" or "subtype" in the grammar for the Enumservice and URI schemes or protocols. The mapping, if any, have to be made explicit in the specification for the Enumservice itself. A registration of a specific Type also have to specify the Subtypes allowed. The only exception to the registration rule is for Types and Subtypes used for experimental purposes, and those are to start with the facet "X-". These elements are unregistered, experimental, and should be used only with the active agreement of the parties exchanging them. The registration mechanism is specified in Section 3. Faltstrom & Mealling Expires May 25, 2003 [Page 6] Internet-Draft ENUM November 2002 3. Registration mechanism for Enumservices Registration of Enumservices requires approval by the IESG and publication of the Enumservice registration as some form of RFC. 3.1 Registration Requirements Service registration proposals are all expected to conform to various requirements laid out in the following sections. 3.1.1 Functionality Requirement An Enumservice registered must be able to function as a selection mechanism when choosing one NAPTR resource record from another. That means that the registration MUST specify what is expected when using that very NAPTR record, and the URI which is the outcome of the use of it. Specifically, a registered Enumservice MUST specify the URI scheme(s) that may be used for the Enumservice, and, when needed, other information which will have to be transfered into the URI resolution process itself (LDAP DNs, transferring of the AUS into the resulting URI, etc). 3.1.2 Naming requirement The name of an Enumservice MUST be unique, conform to the ABNF specified in Section 2.4.2, and MUST NOT start with the facet "X-" which is reserved for experimental, private use. 3.1.3 Security requirement An analysis of security issues is required for for all Enumservices registered. (This is in accordance with the basic requirements for all IETF protocols.) All descriptions of security issues must be as accurate as possible regardless of registration tree. In particular, a statement that there are "no security issues associated with this Enumservice" must not be confused with "the security issues associates with this Enumservice have not been assessed". There is no requirement that Enumservices registered must be secure or completely free from risks. Nevertheless, all known security risks must be identified in the registration of a Enumservice. The security considerations section of all registrations is subject to continuing evaluation and modification. Faltstrom & Mealling Expires May 25, 2003 [Page 7] Internet-Draft ENUM November 2002 Some of the issues that should be looked at in a security analysis of a Enumservice are: 1. Complex Enumservices may include provisions for directives that institute actions on a users resources. In many cases provision can be made to specify arbitrary actions in an unrestricted fashion which may then have devastating results. Especially if there is a risk for a new ENUM lookup, and because of that an infinite loop in the overall resolution process of the E.164. 2. Complex Enumservices may include provisions for directives that institute actions which, while not directly harmful, may result in disclosure of information that either facilitates a subsequent attack or else violates the users privacy in some way. 3. An Enumservice might be targeted for applications that require some sort of security assurance but not provide the necessary security mechanisms themselves. For example, a Enumservice could be defined for storage of confidential medical information which in turn requires an external confidentiality service. 3.1.4 Publication Requirements Proposals for Enumservices registered must be published as RFCs. IANA will retain copies of all Enumservice registration proposals and "publish" them as part of the ENUM Enumservice Registration tree itself. 3.2 Registration procedure Normal IETF processes should be used for publication of the RFC which is the basis of the registration of the Enumservice itself. 3.2.1 IANA Registration Provided that the Enumservice has obtained approval that is necessary, and the RFC is published, IANA will register the Enumservice and make the Enumservice registration available to the community in addition to the RFC publication itself. 3.2.1.1 Location of ENUM Enumservice Registrations Enumservice registrations will be published in the IANA repository and made available via anonymous FTP at the following URI: "ftp:// ftp.isi.edu/in-notes/iana/assignments/enum-services/". Faltstrom & Mealling Expires May 25, 2003 [Page 8] Internet-Draft ENUM November 2002 3.2.1.2 Change Control Change control of Enumservices stay with the IETF via the RFC publication process. Especially, Enumservice registrations may not be deleted; Enumservices which are no longer believed appropriate for use can be declared OBSOLETE by publication of a new RFC and a change to their "intended use" field; such media types will be clearly marked in the lists published by IANA. 3.2.2 Registration Template Enumservice Name: Type(s): Subtype(s): URI Scheme(s): Functional Specification: Security considerations: Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) Author: Any other information that the author deems interesting: Faltstrom & Mealling Expires May 25, 2003 [Page 9] Internet-Draft ENUM November 2002 4. Examples The examples below use theoretical services which uses Enumservices which might not make sense, but they are still used for educational purposes. For example, the protocol used is in some cases exactly the the same string as the URI scheme. That was the specification in RFC 2916, but this default specification of a Enumservice is no longer allowed. All Enumservices need to be registered explicitly by the procedure specified in section Section 3N. 4.1 Example $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:info@example.com!" . IN NAPTR 101 10 "u" "E2U+h323:voice" "!^.*$!h323:info@example.com!" . IN NAPTR 102 10 "u" "E2U+message:mailto" "!^.*$!mailto:info@example.com!" . This describes that the domain 4.3.2.1.6.7.9.8.6.4.e164.arpa is preferably contacted by SIP, secondly via H.323 for voice, and thirdly by SMTP for messaging. Note that the tokens "sip", "message", "h323", "voice" and "mailto" are Types and Subtypes registered with IANA, and they have no implicit connection with the protocols or URI schemes with the same names. In all cases, the next step in the resolution process is to use the resolution mechanism for each of the protocols, (specified by the URI schemes sip, h323 and mailto) to know what node to contact for each. Faltstrom & Mealling Expires May 25, 2003 [Page 10] Internet-Draft ENUM November 2002 5. IANA Considerations This memo requests that the IANA delegate the E164.ARPA domain following instructions to be provided by the IAB. Names within this zone are to be delegated to parties according to the ITU recommendation E.164. The names allocated should be hierarchic in accordance with ITU Recommendation E.164, and the codes should assigned in accordance with that Recommendation. IAB is to coordinate with ITU-T TSB if the technical contact for the domain e164.arpa is to change, as ITU-T TSB has an operational working relationship with this technical contact which needs to be reestablished. Delegations in the zone e164.arpa (not delegations in delegated domains of e164.arpa) should be done after Expert Review, and the IESG will appoint a designated expert. IANA is to create a registry for ENUM Enumservices as specified in Section 3. Whenever a new ENUM Enumservice is registered by the RFC process in the IETF, IANA is at the time of publication of the RFC to register the Enumservice and add a pointer to the RFC itself. Faltstrom & Mealling Expires May 25, 2003 [Page 11] Internet-Draft ENUM November 2002 6. Security Considerations As this system is built on top of DNS, one can not be sure that the information one get back from DNS is more secure than any DNS query. To solve that, the use of DNSSEC [9] for securing and verifying zones is to be recommended. The caching in DNS can make the propagation time for a change take the same amount of time as the time to live for the NAPTR records in the zone that is changed. The use of this in an environment where IP-addresses are for hire (for example, when using DHCP [11]) must therefore be done very carefully. There are a number of countries (and other numbering environments) in which there are multiple providers of call routing and number/name- translation services. In these areas, any system that permits users, or putative agents for users, to change routing or supplier information may provide incentives for changes that are actually unauthorized (and, in some cases, for denial of legitimate change requests). Such environments should be designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes. A large amount of Security Issues have to do with the resolution process itself, and use of the URIs produced by the DDDS mechanism. Those have to be specified in the registration of the ENUM Enumservice used, as specified in Section 3.1.3. Faltstrom & Mealling Expires May 25, 2003 [Page 12] Internet-Draft ENUM November 2002 7. Acknowledgments Support and ideas leading to RFC 2916 have come from people at Ericsson, Bjorn Larsson and the group which implemented this scheme in their lab to see that it worked. Input has also arrived from ITU- T SG2, Working Party 1/2 (Numbering, Routing, Global Mobility and Enumservice Definition), the ENUM working group in the IETF, John Klensin and Leif Sunnegardh. This update of RFC 2916 is created with specific input from: Randy Bush, David Conrad, Richard Hill, Jim Reid, Joakim Stralmark, Robert Walter and James Yu. Faltstrom & Mealling Expires May 25, 2003 [Page 13] Internet-Draft ENUM November 2002 Normative References [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database", RFC 3403, February 2002. [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The URI Resolution Application", RFC 3404, February 2002. [3] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [4] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. Faltstrom & Mealling Expires May 25, 2003 [Page 14] Internet-Draft ENUM November 2002 Non-normative references [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS Standard", RFC 3401, February 2002. [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, February 2002. Authors' Addresses Patrik Faltstrom Cisco Systems Inc Ledasa 273 71 Lovestad Sweden EMail: paf@cisco.com URI: http://www.cisco.com Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US EMail: michael@neonym.net URI: http://www.verisignlabs.com Faltstrom & Mealling Expires May 25, 2003 [Page 15] Internet-Draft ENUM November 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Faltstrom & Mealling Expires May 25, 2003 [Page 16] _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sun Nov 24 10:26:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27674 for ; Sun, 24 Nov 2002 10:26:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAOFSfY32208 for enum-archive@odin.ietf.org; Sun, 24 Nov 2002 10:28:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAOFSbv32203; Sun, 24 Nov 2002 10:28:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAOFRlv32160 for ; Sun, 24 Nov 2002 10:27:47 -0500 Received: from nic-naa.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27627 for ; Sun, 24 Nov 2002 10:25:01 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id gAOFRjjU009750; Sun, 24 Nov 2002 10:27:45 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200211241527.gAOFRjjU009750@nic-naa.net> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= cc: Li Tianbin , enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] Help - A question about ENUM In-Reply-To: Your message of "Sun, 24 Nov 2002 12:22:44 +0100." <0DB135F9-FF9F-11D6-A024-0003934B2128@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9748.1038151665.1@nic-naa.net> Date: Sun, 24 Nov 2002 10:27:45 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > > I'll be appreciated to your help and reply. > To be honest, the word ENUM didn't come out as an acronym. ENUM of course is from the theory of error codes. The original meaning was "Episodic NUMbness" The original authors were struggling with carpel tunnel syndrome, which produced localized numbness in the periphery of the nervous system in the production of the original specification, and with management, which produced generalized numbness at the root of the central nervous system. Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Nov 25 03:49:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22787 for ; Mon, 25 Nov 2002 03:49:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAP8pxt18743 for enum-archive@odin.ietf.org; Mon, 25 Nov 2002 03:51:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAP8pnv18738; Mon, 25 Nov 2002 03:51:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAP8oav18702 for ; Mon, 25 Nov 2002 03:50:36 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22741 for ; Mon, 25 Nov 2002 03:47:41 -0500 (EST) content-class: urn:content-classes:message Subject: Re:[Enum] Help - A question about ENUM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Nov 2002 09:53:28 +0100 Message-ID: <06CF906FE3998C4E944213062009F16202BD64@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Re:[Enum] Help - A question about ENUM Thread-Index: AcKUX6709D2QM0p/RVSTuPHduzwGuw== From: "Stastny Richard" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAP8oav18703 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit >Li Tianbin wrote >I think E.164 Number URI Mapping is better To which I reply: I too Richard STASTNY OeFEG/Telekom Austria Box 147, A-1103 Vienna, Austria tel:+43 664 420 4100 fax:+43 1 797 80 13 mailto:richard.stastny@oefeg.at _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Nov 25 09:15:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28940 for ; Mon, 25 Nov 2002 09:15:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPEI0x03568 for enum-archive@odin.ietf.org; Mon, 25 Nov 2002 09:18:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAPEHqv03560; Mon, 25 Nov 2002 09:17:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAPEGOv03510 for ; Mon, 25 Nov 2002 09:16:24 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28880 for ; Mon, 25 Nov 2002 09:13:38 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Enum] New version of rfc2916bis MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 25 Nov 2002 15:19:25 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620248D8@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] New version of rfc2916bis Thread-Index: AcKTrYSRz5sZohzTSYmh6FthXS5PBQAzhtQw From: "Stastny Richard" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAPEGOv03511 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Comments inline: >1.3 Application of local policy >The priority field in the NAPTR is a request from the holder of the >E.164 in what order the records are to be used. It is to be noted >that the party looking up the records MAY apply a local policy for in >what order the records are to be used based on a combination of the >service fields and URI schemes. As I understand RFC3403, there is an Order and a Preference field, but no Priority field. Since the order field applies IMHO only if not-terminal NAPTRs (no U Flag) are used, here the preference field should be mentioned and the word order should be avoided eg: ...for the preference of the usage of ... This also implies, that the example in 4.1 should be modified accordingly. > > 2.4.2.1 ENUM Services > >An enumservice MUST be registered with the IANA via a description in >an RFC. Enumservices specifications contain the functional >specification (i.e. what it can be used for), the valid protocols, >and the URI schemes that may be returned. Note that there is no >implicit mapping between the textual string "type" or "subtype" in >the grammar for the Enumservice and URI schemes or protocols. The >mapping, if any, have to be made explicit in the specification for >the Enumservice itself. A registration of a specific Type also have >to specify the Subtypes allowed. I still have some problems with this: the best way to check the feasability of a statement is (we just had elections;-) to consider the opposite or an extreme example: The above statement would allow to define a service called sip and to define that the only valid URI-scheme to be returned is h323: This obviously does not make sense and therefore will never happen (I hope;-). The examples (existing and deleted ones) also show, that there WILL always be a kind of mapping between the textual string "type" and "subtype" and the grammar for the Enumservice and URI schemes or protocols, and if this is so, it should be stated. The only exception I can imagine is that the below stated requirement for uniqueness in 3.1.2 may require to chose a different textual string (and also in this case one would not choose a completely misleading one) If I consider the following: > 3.1.1 Functionality Requirement > >An Enumservice registered must be able to function as a selection >mechanism when choosing one NAPTR resource record from another. That >means that the registration MUST specify what is expected when using >that very NAPTR record, and the URI which is the outcome of the use >of it. > >Specifically, a registered Enumservice MUST specify the URI scheme(s) >that may be used for the Enumservice, and, when needed, other >information which will have to be transfered into the URI resolution >process itself (LDAP DNs, transferring of the AUS into the resulting >URI, etc). and I also consider the discussions we had in ATL: that it is not allowed to look at the "right" for the URI scheme, it is obvious, that the "type" or the "subtype" of an enumservices (if it may be usable with more then one URI scheme and may eventually require different selection mechanism when choosing one NAPTR resource record from the other) needs to indicate the URI scheme. Anything other then having the "type" or "subtype" different from the URI scheme would be weird indeed (except if required for uniqueness). > 3.1.2 Naming requirement > >The name of an Enumservice MUST be unique, conform to the ABNF >specified in Section 2.4.2, and MUST NOT start with the facet "X-" >which is reserved for experimental, private use. This is not completely clear to me, especially in combination with the statement in 2.4.2.1 "A registration of a specific Type also have to specify the Subtypes allowed." Of course finally the "type":"subtype" combination (in this order) has to be unique. I also defer that a "type" MUST be unique, especially if the "type" is specifying the "subtypes" (to be used within the type). I also defer from the discussion in ATL that a "type" and a "subtype" need not to be unique, e.g. we may have a "type"=sip and a "subtype"=sip. If now the registration of the "type" specifies the specific "subtypes" allowed within this "types", and also the mapping, the "subtypes" need NOT to be unique. e.g voice:tel and sip:tel is possible to mean something (not necessarily completely) different and the same holds for voice:sip and sip:voice. Therefore "subtypes" tel and sip for enumservice(s) voice:tel and voice:sip are defined with "type" voice and "subtypes" tel and voice for enumservice(s) sip:tel and sip:voice are defined with "type" sip. > 4. Examples > >The examples below use theoretical services which uses Enumservices >which might not make sense, but they are still used for educational >purposes. For example, the protocol used is in some cases exactly >the the same string as the URI scheme. That was the specification in >RFC 2916, but this default specification of a Enumservice is no >longer allowed. All Enumservices need to be registered explicitly by >the procedure specified in section Section 3N. > > 4.1 Example > > $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. > IN NAPTR 100 10 "u" "E2U+sip" > "!^.*$!sip:info@example.com!" . > IN NAPTR 101 10 "u" "E2U+h323:voice" > "!^.*$!h323:info@example.com!" . > IN NAPTR 102 10 "u" "E2U+message:mailto" > "!^.*$!mailto:info@example.com!" . Even if it is stated above that the examples might not make sense, IMHO they should, and also referring to the discussion in ATL and the search for a compromise between the proposals I would prefer to have the following example: > $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. > IN NAPTR 100 10 "u" "E2U+sip" > "!^.*$!sip:info@example.com!" . > IN NAPTR 100 20 "u" "E2U+voice:h323" > "!^.*$!h323:info@example.com!" . > IN NAPTR 100 30 "u" "E2U+message:mailto" > "!^.*$!mailto:info@example.com!" . See also the same order and different preference as mentioned above. >This describes that the domain 4.3.2.1.6.7.9.8.6.4.e164.arpa is >preferably contacted by SIP, secondly via H.323 for voice, and >thirdly by SMTP for messaging. ok, but: >Note that the tokens "sip", >"message", "h323", "voice" and "mailto" are Types and Subtypes >registered with IANA, and they have no implicit >connection with the >protocols or URI schemes with the same names. > First, in the example they HAVE an implicit connection with the same names, so one comes either up with an example showing that there is no explicit connection or the paragraph is reworded e.g.: Note that the tokens "sip", Voice" and "message" are Types registered with IANA, "Voice" and "message" with their resp. Subtypes "h323" and "mailto", and they MAY have no implicit connection with the protocols or URI schemes with the same names. best regards Richard Stastny _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Nov 25 10:00:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01796 for ; Mon, 25 Nov 2002 10:00:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPF2HE05939 for enum-archive@odin.ietf.org; Mon, 25 Nov 2002 10:02:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAPF2Gv05934; Mon, 25 Nov 2002 10:02:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAPF0Vv05857 for ; Mon, 25 Nov 2002 10:00:31 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01668 for ; Mon, 25 Nov 2002 09:57:45 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Sun, 24 Nov 2002 20:48:17 -0500 Subject: RE: [Enum] New version of rfc2916bis From: Michael Mealling To: Stastny Richard Cc: "Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?=" , enum@ietf.org In-Reply-To: <06CF906FE3998C4E944213062009F1620248D8@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F1620248D8@oefeg-s02.oefeg.loc> Organization: HHI, Inc. Message-Id: <1038236289.21972.122.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.0 Date: 25 Nov 2002 09:58:09 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mon, 2002-11-25 at 09:19, Stastny Richard wrote: > Comments inline: > > >1.3 Application of local policy > > >The priority field in the NAPTR is a request from the holder of the > >E.164 in what order the records are to be used. It is to be noted > >that the party looking up the records MAY apply a local policy for in > >what order the records are to be used based on a combination of the > >service fields and URI schemes. > > As I understand RFC3403, there is an Order and a Preference field, > but no Priority field. Since the order field applies > IMHO only if not-terminal NAPTRs (no U Flag) are used, > here the preference field should be mentioned and the word > order should be avoided eg: ...for the preference of the usage of ... > > This also implies, that the example in 4.1 should be > modified accordingly. Incorrect. The term 'Priority' is from the DDDS algorithm. It is equivalent to the Preference field in the NAPTR (Preference is used in deference to DNS experts language preferences). Also, DNS returns records in what ever order the nameserver likes with no gaurantees to the querier that the order will make any sense. I would strongly object to any wording being in the document that suggests any implementation should ignore the Order field or that the ordering step be optional. As an example shows below, records of different order accomlishes one thing while records of the same Order and different Priority/Preference does something completely different. > > 2.4.2.1 ENUM Services > > > >An enumservice MUST be registered with the IANA via a description in > >an RFC. Enumservices specifications contain the functional > >specification (i.e. what it can be used for), the valid protocols, > >and the URI schemes that may be returned. Note that there is no > >implicit mapping between the textual string "type" or "subtype" in > >the grammar for the Enumservice and URI schemes or protocols. The > >mapping, if any, have to be made explicit in the specification for > >the Enumservice itself. A registration of a specific Type also have > >to specify the Subtypes allowed. > > I still have some problems with this: the best way to check > the feasability of a statement is (we just had elections;-) > to consider the opposite or an extreme example: > > The above statement would allow to define a service called > sip and to define that the only valid URI-scheme to be returned > is h323: Yes it would. > This obviously does not make sense and therefore will never happen > (I hope;-). It might make sense. You'd have to read the document that defines what the 'sip' service definition was and why it decided to only allow 'h323' URIs. > The examples (existing and deleted ones) also show, that there > WILL always be a kind of mapping between the textual string > "type" and "subtype" and the grammar for the Enumservice and > URI schemes or protocols, and if this is so, it should be > stated. The only exception I can imagine is that the > below stated requirement for uniqueness in 3.1.2 may require > to chose a different textual string (and also in this > case one would not choose a completely misleading one) Let's make sure we're clear here: there is no relationship between a string in the enumservice field and the URI scheme in the regexp field other than what is defined to be allowed in the enumservice registration document. > If I consider the following: > > > 3.1.1 Functionality Requirement > > > >An Enumservice registered must be able to function as a selection > >mechanism when choosing one NAPTR resource record from another. That > >means that the registration MUST specify what is expected when using > >that very NAPTR record, and the URI which is the outcome of the use > >of it. > > > >Specifically, a registered Enumservice MUST specify the URI scheme(s) > >that may be used for the Enumservice, and, when needed, other > >information which will have to be transfered into the URI resolution > >process itself (LDAP DNs, transferring of the AUS into the resulting > >URI, etc). > > > and I also consider the discussions we had in ATL: that it is not > allowed to look at the "right" for the URI scheme, it is obvious, > that the "type" or the "subtype" of an enumservices (if it may be > usable with more then one URI scheme and may eventually > require different selection mechanism when choosing one NAPTR > resource record from the other) needs to indicate the URI scheme. Incorrect. An enumservice defines what URIs can and might appear in the regexp field. If a particular enumservice limits itself to only allow one particular URI scheme then it must say so. But, IMNSHO, it MUST not replicate the URI scheme directly into the Services field. Those two concepts are not equivalent. A URI identifies a Resource within the systems of URIs. An Enumservice defines a set of inputs, outputs and processes using E.164 numbers and URIs. Those two things are orthogonal and thus REQUIRES an explicitly types mapping function between the two. > Anything other then having the "type" or "subtype" different > from the URI scheme would be weird indeed (except if required > for uniqueness). > > > > 3.1.2 Naming requirement > > > >The name of an Enumservice MUST be unique, conform to the ABNF > >specified in Section 2.4.2, and MUST NOT start with the facet "X-" > >which is reserved for experimental, private use. > > This is not completely clear to me, especially > in combination with the statement in 2.4.2.1 > > "A registration of a specific Type also have > to specify the Subtypes allowed." > > Of course finally the "type":"subtype" combination > (in this order) has to be unique. I also defer that > a "type" MUST be unique, especially if the "type" is specifying > the "subtypes" (to be used within the type). > > I also defer from the discussion in ATL that a > "type" and a "subtype" need not to be unique, > e.g. we may have a "type"=sip and a "subtype"=sip. > > If now the registration of the "type" specifies > the specific "subtypes" allowed within this "types", > and also the mapping, the "subtypes" need NOT to be unique. Sure... hence the discussion about transitive subtypes. > e.g voice:tel and sip:tel is possible to mean something > (not necessarily completely) different and the same holds for > voice:sip and sip:voice. > > Therefore "subtypes" tel and sip for enumservice(s) > voice:tel and voice:sip are defined with "type" voice > > and > "subtypes" tel and voice for enumservice(s) > sip:tel and sip:voice are defined with "type" sip. Correct. That's what the document says. The enumservice is unique. It never says that subtypes are unique.... > > > > 4. Examples > > > >The examples below use theoretical services which uses Enumservices > >which might not make sense, but they are still used for educational > >purposes. For example, the protocol used is in some cases exactly > >the the same string as the URI scheme. That was the specification in > >RFC 2916, but this default specification of a Enumservice is no > >longer allowed. All Enumservices need to be registered explicitly by > >the procedure specified in section Section 3N. > > > > 4.1 Example > > > > $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. > > IN NAPTR 100 10 "u" "E2U+sip" > > "!^.*$!sip:info@example.com!" . > > IN NAPTR 101 10 "u" "E2U+h323:voice" > > "!^.*$!h323:info@example.com!" . > > IN NAPTR 102 10 "u" "E2U+message:mailto" > > "!^.*$!mailto:info@example.com!" . > > Even if it is stated above that the examples might not make sense, > IMHO they should, and also referring to the discussion in ATL > and the search for a compromise between the proposals I would prefer > to have the following example: > > > $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. > > IN NAPTR 100 10 "u" "E2U+sip" > > "!^.*$!sip:info@example.com!" . > > IN NAPTR 100 20 "u" "E2U+voice:h323" > > "!^.*$!h323:info@example.com!" . > > IN NAPTR 100 30 "u" "E2U+message:mailto" > > "!^.*$!mailto:info@example.com!" . I actually like the previous version of the example. I would like some text discussing the fact that the h323 service subtypes based on function class while the last record defines function classes as services and then subtypes based on how that service is expressed. > See also the same order and different preference as mentioned above. Can you elaborate on that statement? The two examples above are actually doing very different things. The example in the document is saying that you have to match explicitly on each group's service field and you can only use the one that matches first. The second is saying that each service is 'equivalent' and the client gets to pick. That's two very different things. > >This describes that the domain 4.3.2.1.6.7.9.8.6.4.e164.arpa is > >preferably contacted by SIP, secondly via H.323 for voice, and > >thirdly by SMTP for messaging. > > ok, but: > > >Note that the tokens "sip", > >"message", "h323", "voice" and "mailto" are Types and Subtypes > >registered with IANA, and they have no implicit > >connection with the > >protocols or URI schemes with the same names. > > > > First, in the example they HAVE an implicit connection with the > same names, so one comes either up with an example showing that > there is no explicit connection or the paragraph is reworded e.g.: > > Note that the tokens "sip", Voice" and "message" are Types registered > with IANA, "Voice" and "message" with their resp. Subtypes "h323" and "mailto", and they MAY have no implicit connection with the protocols > or URI schemes with the same names. No they don't. The only implicit connection exists in the fact that you are making an incorrect assumption about the coincedence between two fields containting the same characters. The three characters 's', 'i' and 'p' that happen to appear in the Enumservice field are nothing more than a pointer into a database managed by the IANA that contains a document which explains rather explicitly what those three letters mean when found in that field. By inserting 'MAY' in there you are suggesting that there is a relationship between the characters found in the enumservice field and something else that is defined outside the enumservice registration documents. -MM -- Michael Mealling HHI, Inc. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Nov 26 04:14:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25192 for ; Tue, 26 Nov 2002 04:14:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQ9HNK11495 for enum-archive@odin.ietf.org; Tue, 26 Nov 2002 04:17:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQ9HCv11486; Tue, 26 Nov 2002 04:17:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQ9Ftv11450 for ; Tue, 26 Nov 2002 04:15:55 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25183 for ; Tue, 26 Nov 2002 04:13:00 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 26 Nov 2002 10:18:48 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620248DA@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Rules, Order, Preference, Priority Thread-Index: AcKUk9UGtI4ClQwuSXusV4Zj6a20zQAkDSpw From: "Stastny Richard" To: "Michael Mealling" Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAQ9Ftv11451 Subject: [Enum] Rules, Order, Preference, Priority Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Monday, November 25, 2002 3:58 PM Michael Mealling wrote > > On Mon, 2002-11-25 at 09:19, Stastny Richard wrote: > > As I understand RFC3403, there is an Order and a Preference > field, but > > no Priority field. Since the order field applies IMHO only if > > not-terminal NAPTRs (no U Flag) are used, here the preference field > > should be mentioned and the word order should be avoided eg: ...for > > the preference of the usage of ... > > > > This also implies, that the example in 4.1 should be > > modified accordingly. > > Incorrect. The term 'Priority' is from the DDDS algorithm. It > is equivalent to the Preference field in the NAPTR > (Preference is used in deference to DNS experts language > preferences). Also, DNS returns records in what ever order > the nameserver likes with no gaurantees to the querier that > the order will make any sense. I would strongly object to any > wording being in the document that suggests any > implementation should ignore the Order field or that the > ordering step be optional. As an example shows below, records > of different order accomlishes one thing while records of the > same Order and different Priority/Preference does something > completely different. Hi MM, I really appreciate your subtle way to tell me to RTFM. I apologize, but I am proud also that at least I found out by myself that priority=preference;-) Nevertheless, I am still a bit confused with use of the order and preference (priority) fields. Lets take the two examples: > > > > > > 4.1 Example > > > > > > $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. > > > IN NAPTR 100 10 "u" "E2U+sip" > > > "!^.*$!sip:info@example.com!" . > > > IN NAPTR 101 10 "u" "E2U+h323:voice" > > > "!^.*$!h323:info@example.com!" . > > > IN NAPTR 102 10 "u" "E2U+message:mailto" > > > "!^.*$!mailto:info@example.com!" . > > > > > > > $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. > > > IN NAPTR 100 10 "u" "E2U+sip" > > > "!^.*$!sip:info@example.com!" . > > > IN NAPTR 100 20 "u" "E2U+voice:h323" > > > "!^.*$!h323:info@example.com!" . > > > IN NAPTR 100 30 "u" "E2U+message:mailto" > > > "!^.*$!mailto:info@example.com!" . > > > See also the same order and different preference as mentioned above. > > Can you elaborate on that statement? The two examples above > are actually doing very different things. The example in the > document is saying that you have to match explicitly on each > group's service field and you can only use the one that > matches first. The second is saying that each service is > 'equivalent' and the client gets to pick. That's two very > different things. > > Since we are trying to define the minimum requirements on ENUM clients for interoperability, a correct understanding of the use of order and preference is important. Order is defined in RFC3403: ORDER A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed in order to accurately represent the ordered list of Rules. The ordering is from lowest to highest. If two records have the same order value then they are considered to be the same rule and should be selected based on the combination of the Preference values and Services offered. In RFC2916bis it is stated: 2.4.1 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 [3]. 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. Maybe I get something wrong here, my original idea of ordering was that if I have a set of rules, I MUST order them first according to the order field and process them one after the other until an "U" flag is encountered. Then I may look at the enumservice field and eventually retrieve the URI. What you are saying is the following (I am trying to write an developers guide here): Order the NAPTRs according to the order field (and if the same order value by preference) and then start matching the enumservice(s) supported by your client with the lowest order. If a match is found, take it and ignore the rest of the NAPTRs, exept if you have a NAPTR with the same order. Then you may take the one with the lowest number in the preference field, but you may also take one with higher preference. The above is valid in our case for what we call application specific ENUM clients, e.g. an SIP-Phone. Other clients we have are displaying all NAPTRs available. We call this generic ENUM clients. In this case the NAPTRs are displayed just by order and preference and it up to the user to make sense out of it. I can live with this, but I still have some doubt. If I take the definition of preference in RFC3404: PREFERENCE Although it is called "preference" in deference to DNS terminology, this field is equivalent to the Priority value in the DDDS Algorithm. It is a 16-bit unsigned integer that specifies the order in which NAPTR records with equal Order values SHOULD be processed, low numbers being processed before high numbers. This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. A client MAY look at records with higher preference values if it has a good reason to do so such as not supporting some protocol or service very well. It seems to me that in common words the order field in the NAPTRs according to your explanation may give the "preference" of the called party by type of communication he prefers to be contacted, e.g. the called user prefers sip above h323, if both are there. The preference field gives the "preference" for equivalent types of communication, e.g. if two sip NAPTR are there, you may point to two different proxies, but prefers the first one. If order and preference is the same, you may use this for loadsharing at random. There may also be another interpretation: I as a called user do not care in principle, the calling user may chose in the first place, but if the calling user is in doubt, may "preferences" are by the numbers in the preference field. Since I have heard all types of explanations about order and preference, I want to have settled this issue finally. best regards Richard Stastny _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Nov 26 08:18:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29970 for ; Tue, 26 Nov 2002 08:18:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQDKod25236 for enum-archive@odin.ietf.org; Tue, 26 Nov 2002 08:20:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQDKiv25231; Tue, 26 Nov 2002 08:20:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQDHhv25124 for ; Tue, 26 Nov 2002 08:17:43 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29719; Tue, 26 Nov 2002 08:14:57 -0500 (EST) Message-Id: <200211261314.IAA29719@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 26 Nov 2002 08:14:57 -0500 Subject: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-02.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : The E.164 to URI DDDS Application (ENUM) Author(s) : P. Faltstrom, M. Mealling Filename : draft-ietf-enum-rfc2916bis-02.txt Pages : 16 Date : 2002-11-25 This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC WWWW. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC WWWW. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-rfc2916bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-rfc2916bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-25134642.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-rfc2916bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-rfc2916bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-25134642.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Nov 26 15:33:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19432 for ; Tue, 26 Nov 2002 15:33:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQKa3X23828 for enum-archive@odin.ietf.org; Tue, 26 Nov 2002 15:36:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQKZvv23820; Tue, 26 Nov 2002 15:35:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQKYPv23738 for ; Tue, 26 Nov 2002 15:34:25 -0500 Received: from blount.mail.mindspring.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19394 for ; Tue, 26 Nov 2002 15:31:36 -0500 (EST) Received: from user-uivenvf.dsl.mindspring.com ([165.247.95.239] helo=dick.ix.netcom.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18GmP7-0002AH-00; Tue, 26 Nov 2002 15:33:58 -0500 Message-Id: <5.2.0.9.2.20021126150213.03ecba08@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 26 Nov 2002 15:34:59 -0500 To: Michael Mealling , Stastny Richard From: Richard Shockey Subject: RE: [Enum] New version of rfc2916bis Cc: =?iso-8859-1?Q?=22Patrik_F=E4ltstr=F6m=22?= , enum@ietf.org In-Reply-To: <1038236289.21972.122.camel@blackdell.neonym.net> References: <06CF906FE3998C4E944213062009F1620248D8@oefeg-s02.oefeg.loc> <06CF906FE3998C4E944213062009F1620248D8@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 09:58 AM 11/25/2002 -0500, Michael Mealling wrote: >On Mon, 2002-11-25 at 09:19, Stastny Richard wrote: > > Comments inline: OK my two cents worth.... > > > > This also implies, that the example in 4.1 should be > > modified accordingly. > >Incorrect. The term 'Priority' is from the DDDS algorithm. It is >equivalent to the Preference field in the NAPTR (Preference is used in >deference to DNS experts language preferences). Also, DNS returns >records in what ever order the nameserver likes with no gaurantees to >the querier that the order will make any sense. I would strongly object >to any wording being in the document that suggests any implementation >should ignore the Order field or that the ordering step be optional. >As an example shows below, records of different order accomlishes one >thing while records of the same Order and different Priority/Preference >does something completely different. ack... priority=preference ... I think Richard understands that now. > > The examples (existing and deleted ones) also show, that there > > WILL always be a kind of mapping between the textual string > > "type" and "subtype" and the grammar for the Enumservice and > > URI schemes or protocols, and if this is so, it should be > > stated. The only exception I can imagine is that the > > below stated requirement for uniqueness in 3.1.2 may require > > to chose a different textual string (and also in this > > case one would not choose a completely misleading one) > >Let's make sure we're clear here: there is no relationship between a >string in the enumservice field and the URI scheme in the regexp field >other than what is defined to be allowed in the enumservice registration >document. yes Mike ... as you say ..you could define a enumservice field 'voice' and the only valid URI scheme would be SIP ... and another enumservice field 'barf" and the only valid URI scheme would be h323. Also ... you can define a enumservice field 'sip' and the only valid URI is scheme is sip Now that is a extreme example :-) but I think illustrative of what your point is. Though some of us accept that the logical ordering is type=sip subtype=voice et.al. and not the other way around. Richard ..now dont get started.. :-) But if a enumservice field 'voice' is established with subtypes sip and h323 then IMHO that there is functional equivalency between E2U+voice:sip and E2U+sip:voice am I making sense here? That many of us would like to use sip and h323 as enumservices has to do with how the NAPTR records are processed by client user agents and that is where we still need clarification. This is a old problem that goes back quite a while and Richard is entirely correct is wanting a more concrete explanation. Jon James Yu and I brought this up a long time ago. I have always understood the parsing of the NAPTR records upon receipt to occur FIRST on the enumservice field to find the service(s) desired. There is NO look ahead to the URI's in the regexp. Once those records for a enumservice are chosen a further selection can be made on the order field as you have in the example so that if a CU/A sees two sip enumservices it can properly select which one to process first. I thought we were agreeing that two similar services should maintain the same preference value. The clarification as I see it is what is the proper relationship to order and preference (priority) in processing. We definitely need better text here. > > > > and I also consider the discussions we had in ATL: that it is not > > allowed to look at the "right" for the URI scheme, it is obvious, > > that the "type" or the "subtype" of an enumservices (if it may be > > usable with more then one URI scheme and may eventually > > require different selection mechanism when choosing one NAPTR > > resource record from the other) needs to indicate the URI scheme. > >Incorrect. An enumservice defines what URIs can and might appear in the >regexp field. If a particular enumservice limits itself to only allow >one particular URI scheme then it must say so. But, IMNSHO, it MUST not >replicate the URI scheme directly into the Services field. Those two >concepts are not equivalent. A URI identifies a Resource within the >systems of URIs. An Enumservice defines a set of inputs, outputs and >processes using E.164 numbers and URIs. Those two things are orthogonal >and thus REQUIRES an explicitly types mapping function between the two. Mike I'm lost with this comment. Could you elaborate? > > > > Of course finally the "type":"subtype" combination > > (in this order) has to be unique. I also defer that > > a "type" MUST be unique, especially if the "type" is specifying > > the "subtypes" (to be used within the type). > > > > I also defer from the discussion in ATL that a > > "type" and a "subtype" need not to be unique, > > e.g. we may have a "type"=sip and a "subtype"=sip. > > > > If now the registration of the "type" specifies > > the specific "subtypes" allowed within this "types", > > and also the mapping, the "subtypes" need NOT to be unique. > >Sure... hence the discussion about transitive subtypes. > > > e.g voice:tel and sip:tel is possible to mean something > > (not necessarily completely) different and the same holds for > > voice:sip and sip:voice. well this is the problem I have ... this could be very very confusing to implementers if it is held that these two could actually define different things assuming that a CU/A is going to look at these fields first. unless,as you point out, that in the registration document for 'voice' it is explicitly understood that these MUST be treated as equivalent. > > > > > 4. Examples > > > > > >The examples below use theoretical services which uses Enumservices > > >which might not make sense, but they are still used for educational > > >purposes. For example, the protocol used is in some cases exactly > > >the the same string as the URI scheme. That was the specification in > > >RFC 2916, but this default specification of a Enumservice is no > > >longer allowed. All Enumservices need to be registered explicitly by > > >the procedure specified in section Section 3N. > > > > > > 4.1 Example > > > > > > $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. > > > IN NAPTR 100 10 "u" "E2U+sip" > > > "!^.*$!sip:info@example.com!" . > > > IN NAPTR 101 10 "u" "E2U+h323:voice" > > > "!^.*$!h323:info@example.com!" . > > > IN NAPTR 102 10 "u" "E2U+message:mailto" > > > "!^.*$!mailto:info@example.com!" . > > > > Even if it is stated above that the examples might not make sense, > > IMHO they should, and also referring to the discussion in ATL > > and the search for a compromise between the proposals I would prefer > > to have the following example: > > > > > $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. > > > IN NAPTR 100 10 "u" "E2U+sip" > > > "!^.*$!sip:info@example.com!" . > > > IN NAPTR 100 20 "u" "E2U+voice:h323" > > > "!^.*$!h323:info@example.com!" . > > > IN NAPTR 100 30 "u" "E2U+message:mailto" > > > "!^.*$!mailto:info@example.com!" . > >I actually like the previous version of the example. I would like some >text discussing the fact that the h323 service subtypes based on >function class while the last record defines function classes as >services and then subtypes based on how that service is expressed. > > > See also the same order and different preference as mentioned above. > >Can you elaborate on that statement? The two examples above are actually >doing very different things. The example in the document is saying that >you have to match explicitly on each group's service field and you can >only use the one that matches first. The second is saying that each >service is 'equivalent' and the client gets to pick. That's two very >different things. exactly >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Nov 26 17:31:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23809 for ; Tue, 26 Nov 2002 17:31:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQMXTj32112 for enum-archive@odin.ietf.org; Tue, 26 Nov 2002 17:33:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQMXRv32107; Tue, 26 Nov 2002 17:33:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQMWev32049 for ; Tue, 26 Nov 2002 17:32:40 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23763 for ; Tue, 26 Nov 2002 17:29:48 -0500 (EST) content-class: urn:content-classes:message Subject: AW: [Enum] New version of rfc2916bis MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Tue, 26 Nov 2002 23:35:37 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620248DE@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] New version of rfc2916bis Thread-Index: AcKVi56sx2hsjNd4TPiJGtlcmmA/cAAB3DwX From: "Stastny Richard" To: "Richard Shockey" , "Michael Mealling" Cc: =?utf-8?Q?=22Patrik_F=C3=A4ltstr=C3=B6m=22?= , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gAQMWev32050 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Rich Shockey wrote: >ack... priority=preference ... I think Richard understands that now. Thanks, you all are really so sympathetic to morons like myself ;-) >Though some of us accept that the logical ordering is >type=sip subtype=voice et.al. and not the other way around. >Richard ..now dont get started.. :-) I keep cool now, but wait;-) >But if a enumservice field 'voice' is established with subtypes sip and >h323 then IMHO that there is functional equivalency between >E2U+voice:sip and >E2U+sip:voice >am I making sense here? I understand what you mean, but IMHO there is no equivalency automatically and this comes out of the text of RFC2916bis and also the explanation I got from MM: -citation MM begin- The three characters 's', 'i' and 'p' that happen to appear in the Enumservice field are nothing more than a pointer into a database managed by the IANA that contains a document which explains rather explicitly what those three letters mean when found in that field. -citation MM end- So if a define an enumservice with type voice and subtype sip in a RFC according to RFC2916bis, so the characters voice:sip are just a pointer into a database document ..... If you define an enumservice with type sip and subtype voice in another RFC so the characters sip:voice are just a pointer to another document ..... I asked also: > e.g voice:tel and sip:tel is possible to mean something > (not necessarily completely) different and the same holds for > voice:sip and sip:voice. > > Therefore "subtypes" tel and sip for enumservice(s) > voice:tel and voice:sip are defined with "type" voice > > and > "subtypes" tel and voice for enumservice(s) > sip:tel and sip:voice are defined with "type" sip. and got the answer: MM: Correct. That's what the document says. The enumservice is unique. It never says that subtypes are unique.... The descriptions in the two documents for voice:sip and sip:voice MAY be equivalent, but need not to be. And if they are different, I do not think that clients have a problems to separate the functions. Summary: you have two different enumservices voice:sip and sip:voice defined If they are equivalent or not is depending on the description. Since I know only the description for voice:sip and have none for sip:voice, I do not know yet. >That many of us would like to use sip and h323 as enumservices has to do >with how the NAPTR records are processed by client user agents and that is >where we still need clarification. >This is a old problem that goes back quite a while and Richard is entirely >correct is wanting a more concrete explanation. Jon James Yu and I brought >this up a long time ago. >I have always understood the parsing of the NAPTR records upon receipt to >occur FIRST on the enumservice field to find the service(s) desired. There >is NO look ahead to the URI's in the regexp. Once those records for a >enumservice are chosen a further selection can be made on the order field >as you have in the example so that if a CU/A sees two sip enumservices it >can properly select which one to process first. >I thought we were agreeing that two similar services should maintain the >same preference value. >The clarification as I see it is what is the proper relationship to order >and preference (priority) in processing. >We definitely need better text here. Definitive, this is urgent. I am still awaiting an answer from MM on these issues (see my other e-mail) and I need the answer this week because we need to define the minimum requirements for the clients and I have to submit asap to ETSI. And I want the order and preference=priority also clarified. > > > > and I also consider the discussions we had in ATL: that it is not > > allowed to look at the "right" for the URI scheme, it is obvious, > > that the "type" or the "subtype" of an enumservices (if it may be > > usable with more then one URI scheme and may eventually > > require different selection mechanism when choosing one NAPTR > > resource record from the other) needs to indicate the URI scheme. > >Incorrect. An enumservice defines what URIs can and might appear in the >regexp field. If a particular enumservice limits itself to only allow >one particular URI scheme then it must say so. But, IMNSHO, it MUST not >replicate the URI scheme directly into the Services field. Those two >concepts are not equivalent. A URI identifies a Resource within the >systems of URIs. An Enumservice defines a set of inputs, outputs and >processes using E.164 numbers and URIs. Those two things are orthogonal >and thus REQUIRES an explicitly types mapping function between the two. >Mike I'm lost with this comment. Could you elaborate? I was lost too, especially with the MUST not replicate part If I define voice:foo to be a voice service using only the sip URI scheme and protocol, this is ok. According to the above wording voice:sip is not ok (also sip:voice is not ok;-). > > > > Of course finally the "type":"subtype" combination > > (in this order) has to be unique. I also defer that > > a "type" MUST be unique, especially if the "type" is specifying > > the "subtypes" (to be used within the type). > > > > I also defer from the discussion in ATL that a > > "type" and a "subtype" need not to be unique, > > e.g. we may have a "type"=sip and a "subtype"=sip. > > > > If now the registration of the "type" specifies > > the specific "subtypes" allowed within this "types", > > and also the mapping, the "subtypes" need NOT to be unique. > >Sure... hence the discussion about transitive subtypes. > > > e.g voice:tel and sip:tel is possible to mean something > > (not necessarily completely) different and the same holds for > > voice:sip and sip:voice. >well this is the problem I have ... this could be very very confusing to >implementers if it is held that these two could actually define different >things assuming that a CU/A is going to look at these fields first. >unless,as you point out, that in the registration document for 'voice' it >is explicitly understood that these MUST be treated as equivalent. as I explained above, its only pointers to a document and my designers are very clever ;-) > > > > > 4. Examples > > > > > >The examples below use theoretical services which uses Enumservices > > >which might not make sense, but they are still used for educational > > >purposes. For example, the protocol used is in some cases exactly > > >the the same string as the URI scheme. That was the specification in > > >RFC 2916, but this default specification of a Enumservice is no > > >longer allowed. All Enumservices need to be registered explicitly by > > >the procedure specified in section Section 3N. > > > > > > 4.1 Example > > > > > > $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. > > > IN NAPTR 100 10 "u" "E2U+sip" > > > "!^.*$!sip:info@example.com!" . > > > IN NAPTR 101 10 "u" "E2U+h323:voice" > > > "!^.*$!h323:info@example.com!" . > > > IN NAPTR 102 10 "u" "E2U+message:mailto" > > > "!^.*$!mailto:info@example.com !" . > > > > Even if it is stated above that the examples might not make sense, > > IMHO they should, and also referring to the discussion in ATL > > and the search for a compromise between the proposals I would prefer > > to have the following example: > > > > > $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. > > > IN NAPTR 100 10 "u" "E2U+sip" > > > "!^.*$!sip:info@example.com!" . > > > IN NAPTR 100 20 "u" "E2U+voice:h323" > > > "!^.*$!h323:info@example.com!" . > > > IN NAPTR 100 30 "u" "E2U+message:mailto" > > > "!^.*$!mailto:info@example.com !" . > >I actually like the previous version of the example. I would like some >text discussing the fact that the h323 service subtypes based on >function class while the last record defines function classes as >services and then subtypes based on how that service is expressed. > > > See also the same order and different preference as mentioned above. > >Can you elaborate on that statement? The two examples above are actually >doing very different things. The example in the document is saying that >you have to match explicitly on each group's service field and you can >only use the one that matches first. The second is saying that each >service is 'equivalent' and the client gets to pick. That's two very >different things. >exactly See my other e-mail, I am still having problems here. I elaborated in the other e-mail. I am happy with any explanation. Richard Stastny _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Nov 26 20:49:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01114 for ; Tue, 26 Nov 2002 20:49:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAR1peE11800 for enum-archive@odin.ietf.org; Tue, 26 Nov 2002 20:51:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAR1pav11792; Tue, 26 Nov 2002 20:51:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAR1oov11754 for ; Tue, 26 Nov 2002 20:50:50 -0500 Received: from tisch.mail.mindspring.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01102 for ; Tue, 26 Nov 2002 20:47:58 -0500 (EST) Received: from user-2ivek9b.dialup.mindspring.com ([165.247.81.43] helo=dick.ix.netcom.com) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18GrLP-0005K4-00; Tue, 26 Nov 2002 20:50:28 -0500 Message-Id: <5.2.0.9.2.20021126203840.04006940@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 26 Nov 2002 20:51:30 -0500 To: "Stastny Richard" , "Michael Mealling" From: Richard Shockey Subject: Re: AW: [Enum] New version of rfc2916bis Cc: =?iso-8859-1?Q?=22Patrik_F=C3=A4ltstr=C3=B6m=22?= , In-Reply-To: <06CF906FE3998C4E944213062009F1620248DE@oefeg-s02.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > > >Richard ..now dont get started.. :-) >I keep cool now, but wait;-) > > >But if a enumservice field 'voice' is established with subtypes sip and > >h323 then IMHO that there is functional equivalency between > > >E2U+voice:sip and > >E2U+sip:voice > > >am I making sense here? >I understand what you mean, but IMHO there is no equivalency >automatically >and this comes out of the text of RFC2916bis and also the >explanation I got from MM: I know ... MM can state that the two are functionally non-equivalent ..but then If I was some poor software development manager trying to tell my code jockeys what to do ... I'd have a problem and you are right this is way too ambiguous for my tastes. > > -citation MM begin- >The three characters 's', 'i' >and 'p' that happen to appear in the Enumservice field are nothing more >than a pointer into a database managed by the IANA that contains a >document which explains rather explicitly what those three letters mean >when found in that field. >-citation MM end- > >So if a define an enumservice with type voice and subtype sip in a RFC >according to RFC2916bis, so the characters voice:sip are just a pointer into >a database document ..... > >If you define an enumservice with type sip and subtype voice in another RFC >so the characters sip:voice are just a pointer to another document ..... yep... it looks simple but it is not. > >And if they are different, I do not think that clients have a problems >to separate the functions. tell that to a coder.... But Richard ..this also highlights the direction enumservices compendium needs to take. Broken apart with clear and unambiguous definitions of type and subtype and what URI to expect for each option each document can stand on its own. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Nov 27 06:25:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06027 for ; Wed, 27 Nov 2002 06:25:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARBS5W17549 for enum-archive@odin.ietf.org; Wed, 27 Nov 2002 06:28:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARBRtv17542; Wed, 27 Nov 2002 06:27:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARBQnv17485 for ; Wed, 27 Nov 2002 06:26:49 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05988 for ; Wed, 27 Nov 2002 06:24:03 -0500 (EST) content-class: urn:content-classes:message Subject: RE: AW: [Enum] New version of rfc2916bis - new compendium MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 27 Nov 2002 12:29:52 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620248E2@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: AW: [Enum] New version of rfc2916bis - new compendium Thread-Index: AcKVt9E7GuSA01bgRreDku2n04ngcgATrrWQ From: "Stastny Richard" To: "Richard Shockey" , "Michael Mealling" Cc: =?iso-8859-1?B?IlBhdHJpayBGw6RsdHN0csO2bSI=?= , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gARBQnv17486 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Rich wrote in reply to me: > >And if they are different, I do not think that clients have > a problems > >to separate the functions. > > tell that to a coder.... > > But Richard ..this also highlights the direction enumservices > compendium > needs to take. > > Broken apart with clear and unambiguous definitions of type > and subtype and > what URI to expect for each option each document can stand on its own. > Yes, Rich, we already discussed this and are planning to do this (after overcoming our depressions ;-). The question is only if we should keep an (extremely slimmed down) informational brander-compendium as a framework (high level outline) and overview. It could also give information on the usage and meaning of order and preference(or was it priority?) if you use combinations of enumservices. Regarding this issue, see also the e-mail below I received from Mark Enzmann: From: Enzmann, Mark [mailto:Mark.Enzmann@cingular.com] Sent: Friday, November 22, 2002 11:20 PM To: Stastny Richard Cc: Clif Campbell (E-mail); Tom Richter (E-mail) Subject: RE: [Enum] Compendium on enumservices registration Richard, I also believe that the compendium should be a workgroup document. I would propose that in order to simplify the document and give it more value, perhaps we can change it into more of a high level outline. That is, start by defining the categories, then the services related to each category. The detailed service description could be in another document. This would be similar to the work being done in sipping as relates to conferencing. There has been effort expended to pull this document together and I hate to see it wasted. In addition, should the idea of an overall services document with the details in individual service detail description documents be implemented, it should be simpler to add a newly defined service into what would be a live "menu" of services. You may share this with the list as you see appropriate. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Nov 27 17:14:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29897 for ; Wed, 27 Nov 2002 17:14:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARMH2429387 for enum-archive@odin.ietf.org; Wed, 27 Nov 2002 17:17:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARMGvv29380; Wed, 27 Nov 2002 17:16:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARMFpv29355 for ; Wed, 27 Nov 2002 17:15:51 -0500 Received: from blount.mail.mindspring.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29851 for ; Wed, 27 Nov 2002 17:13:00 -0500 (EST) Received: from user-uivenoj.dsl.mindspring.com ([165.247.95.19] helo=dick.ix.netcom.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18HASx-0005vK-00; Wed, 27 Nov 2002 17:15:31 -0500 Message-Id: <5.2.0.9.2.20021127160200.0412a170@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 27 Nov 2002 16:04:53 -0500 To: "Stastny Richard" , "Michael Mealling" From: Richard Shockey Subject: RE: AW: [Enum] New version of rfc2916bis - new compendium Cc: , In-Reply-To: <06CF906FE3998C4E944213062009F1620248E2@oefeg-s02.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At >Yes, Rich, we already discussed this and are planning to do this >(after overcoming our depressions ;-). > >The question is only if we should keep an (extremely slimmed down) >informational brander-compendium as a framework (high level outline) and >overview. >It could also give information on the usage and meaning of order >and preference(or was it priority?) if you use combinations of enumservices. > >Regarding this issue, see also the e-mail below I received from Mark Enzmann: > >From: Enzmann, Mark [mailto:Mark.Enzmann@cingular.com] >Sent: Friday, November 22, 2002 11:20 PM >To: Stastny Richard >Cc: Clif Campbell (E-mail); Tom Richter (E-mail) >Subject: RE: [Enum] Compendium on enumservices registration > > >Richard, >I also believe that the compendium should be a workgroup document. I >would propose that in order to simplify the document and give it more >value, perhaps we can change it into more of a high level outline. That >is, start by defining the categories, then the services related to each >category. The detailed service description could be in another document. >This would be similar to the work being done in sipping as relates to >conferencing. > >There has been effort expended to pull this document together and I hate >to see it wasted. In addition, should the idea of an overall services >document with the details in individual service detail description >documents be implemented, it should be simpler to add a newly defined >service into what would be a live "menu" of services. > >You may share this with the list as you see appropriate. Actually this is a excellent suggestion but may I suggest that it take the form of a "Requirements for enumservices" This is a well known tried and true IETF model and one that is being used with great success in SIPPING. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum