From enum-bounces@ietf.org Tue Jul 04 06:14:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxhvW-0006ml-Dz; Tue, 04 Jul 2006 06:14:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxhvV-0006mg-E6 for enum@ietf.org; Tue, 04 Jul 2006 06:14:41 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxhvU-00028a-56 for enum@ietf.org; Tue, 04 Jul 2006 06:14:41 -0400 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Tue, 04 Jul 2006 12:14:38 +0200 id 0007C030.44AA3F8E.00001390 Message-ID: <44AA3F75.9070106@enum.at> Date: Tue, 04 Jul 2006 12:14:13 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Enum] call for slides... X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi, if you're going to present in Montreal, and already have your slides in a usable state - please mail them to me or the chairs for uploading to the proceedings page. Especially remote participants (and me ;) prefer to have the slides available a few days in advance - and I'd like to avoid the bouquet of usb sticks piling up near my computer on monday, 08:57am. They don't need to be the final ones, we can always replace your slides with an updated version in the unusual :) case you make late changes. thanks, Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 04 09:24:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxktT-00079d-Rq; Tue, 04 Jul 2006 09:24:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxktS-00079W-U5 for enum@ietf.org; Tue, 04 Jul 2006 09:24:46 -0400 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxktR-0001sc-Ig for enum@ietf.org; Tue, 04 Jul 2006 09:24:46 -0400 Received: from [195.54.233.69] (HELO [195.54.233.69]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTP id 53354 for enum@ietf.org; Tue, 04 Jul 2006 14:24:44 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <87E1D4A1-2CF8-4915-84C9-86BCC0AB5641@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Date: Tue, 4 Jul 2006 14:24:43 +0100 To: IETF ENUM WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Enum] Assessors wanted for UK T1 RFP X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jim@ukenumgroup.org List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I apologise in advance for sending the message below as it's somewhat off-topic for this list. However, I expect there are many people on this list who may be interested. The UK ENUM Consortium, a non-profit company, is about to be formed to oversee commercial ENUM activities in the UK. Its first item of business will be to issue an RFP for the operation of the Tier-1 registry contract, probably in Q3 this year. UKEC is expected to appoint a panel of independent assessors to examine the RFP responses and make recommendations. The assessors should have the expected skill sets: technical, financial, business, legal/governance, etc. Anyone wishing to be considered as an assessor can contact me, in confidence if necessary. I will be happy to answer any questions. Though some details -- time-lines, processes -- have still to be determined by UKEC. It is also likely that the appointed assessors will be consulted about how the RFP process is done. If you know of anyone suitable for these roles -- including yourself -- please let me know. Do not cc your reply to this list. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jul 05 17:35:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyF20-00019U-8O; Wed, 05 Jul 2006 17:35:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyF1y-00019O-Gt for enum@ietf.org; Wed, 05 Jul 2006 17:35:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyDoL-0001Ej-OB for enum@ietf.org; Wed, 05 Jul 2006 16:17:25 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyDa2-0006lj-G8 for enum@ietf.org; Wed, 05 Jul 2006 16:02:40 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k65K2ccm032404 for ; Wed, 5 Jul 2006 13:02:38 -0700 From: "Richard Shockey" To: Date: Wed, 5 Jul 2006 16:02:10 -0400 Message-ID: <020201c6a06d$e6ae9b80$2e201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcagbeXN5IwNYePOQ5W6ZnkJXGoOvA== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: -0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Subject: [Enum] FINAL AGENDA: IETF 66 Telephone Number Mapping (ENUM) WG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Agenda of the 66th IETF Meeting July 9-14, 2006 FINAL AGENDA: IETF 66 Telephone Number Mapping (ENUM) WG Chair(s): Patrik Faltstrom Richard Shockey WG Secretary: Alexander Mayrhofer RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com RAI Area Advisor: Jon Peterson MONDAY, July 10, 2006 0800-1800 IETF Registration - Foyer 500D 0800-0900 Continental Breakfast - Foyer 500D 0900-1130 Morning Session I Room 520ABC RAI enum Telephone Number Mapping WG Review of Agenda Status of Drafts and in Drafts the Queue Overview - Alexander Mayhofer WG Secretary ENUM Validation Architecture ENUM PSTN ENUM VOID Etal. ************************************ 10 M EDNS0 issues in ENUM 5M Experiences Draft Final Final issues? Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-05.txt Pages : 36 Date : 2006-6-29 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is advisory, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-05.txt ************************************* 10M General Agreement to Go to Last Call on .... Title : IANA Registration for vCard Enumservice Author(s) : A. Mayrhofer Filename : draft-ietf-enum-vcard-02.txt Pages : 9 Date : 2006-6-13 This memo registers the Enumservice "vCard" with the subtypes "plain", "xml" and "rdf" using the URI schemes "http" and "https" according to the IANA Enumservice registration process described in RFC 3671. This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number. Information gathered from those vCards could be used before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-vcard-02.txt Title : A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services Author(s) : R. Mahy Filename : draft-ietf-enum-im-service-01.txt Pages : 5 Date : 2006-6-22 This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs in ENUM. http://www.ietf.org/internet-drafts/draft-ietf-enum-im-service-01.txt A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services draft-mahy-enum-calendar-service-00.txt http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-01.txt Title : ENUM Validation Token Format Definition Author(s) : O. Lendl Filename : draft-ietf-enum-validation-token-01.txt Pages : 16 Date : 2006-2-13 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-token-01.txt http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-0?.txt When submitted ****************************************************************** 10 Min Title : Guide and Template for IANA Registrations of Enumervices Author(s) : J. Livingood, et al. Filename : draft-ietf-enum-enumservices-guide-01.txt Pages : 15 Date : 2006-6-27 This document provides a guide to and template for the creation of new IANA registration of ENUM services. It is also to be used for updates of existing IANA registrations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-01.tx t ******************************************************************** New Business 10 Min Title : IANA Registration for an Enumservice to Hint to E.164 Resolution Namespaces (ERN) Author(s) : R. Stastny Filename : draft-stastny-enum-ern-00.txt Pages : 11 Date : 2006-6-5 This document registers the Enumservice type "ern" and subtype "http" using the URI scheme 'http', as well as the subtype "urn" using the URI scheme 'urn' as per the IANA registration process defined in the ENUM specification RFC 3761. This Enumservice is used to provide a hint in ENUM to an E.164 Resolution Namespace a service provider chooses to populate with E.164 numbers to be shared within a limited group of other service providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stastny-enum-ern-00.txt Old Business. 10M Title : Combined User and Infrastructure ENUM in the e164.arpa tree Author(s) : M. Haberler, R. Stastny Filename : draft-haberler-carrier-enum-03.txt Pages : 11 Date : 2006-6-23 This memo defines an interim solution for Infrastructure ENUM to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice until the long-term solution is approved. This interim solution will be deprecated after deployment of the long-term solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-03.txt 15 Min Title : The ENUM Branch Location Record Author(s) : O. Lendl Filename : draft-lendl-enum-branch-location-record-02.txt Pages : 7 Date : 2006-6-26 This documents defines the ENUM Branch Location record which is used to indicate where the ENUM tree for special ENUM application is located. The primary application for the EBL is to enable a temporary solution for the infrastructure ENUM tree. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lendl-enum-branch-location-record- 02.txt 15Min Infrastructure ENUM root? http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-00.txt Open Session Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 06 15:50:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZrP-0008FC-NW; Thu, 06 Jul 2006 15:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZrO-0008F4-Ug; Thu, 06 Jul 2006 15:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZrN-0002EZ-Mv; Thu, 06 Jul 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k66Jo11u008175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jul 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FyZrN-0004vD-HH; Thu, 06 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 06 Jul 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-calendar-service-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --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 : A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services Author(s) : R. Mahy Filename : draft-ietf-enum-calendar-service-01.txt Pages : 6 Date : 2006-7-6 This document registers a Telephone Number Mapping (ENUM) service for Internet Calendaring Services. Specifically, this document focuses on provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-calendar-service-01.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-calendar-service-01.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: <2006-7-6111658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-calendar-service-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-calendar-service-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-6111658.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Sun Jul 09 06:43:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzWl6-0008WE-SG; Sun, 09 Jul 2006 06:43:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzWl5-0008W9-JQ for enum@ietf.org; Sun, 09 Jul 2006 06:43:27 -0400 Received: from norman.insensate.co.uk ([213.152.49.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzWl4-0004hI-6f for enum@ietf.org; Sun, 09 Jul 2006 06:43:27 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 9A66A8EC4B; Sun, 9 Jul 2006 11:43:22 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Date: Sun, 9 Jul 2006 11:43:21 +0100 To: enum@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Alexander Mayrhofer Subject: [Enum] changes to experiences and edns0 drafts X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Alex, folks, Sorry about the delay, but here are the changes in the current versions of the experiences and edns0 drafts. ------------------ Changes in experiences-05 ---- Highlighted that terms do not have RFC 2119 meaning - this does not obsolete or update the standards (3761 and 340x). It describes "what's out there" and proposes interpretations of ambiguous sections of the standards. Changed all MUST/SHOULD/MAY to lower case throughout, to emphasise this. Added explicit reference to E.164. Spelt out acronym meanings on first use. Corrected use of terms that have specific DNS meanings (owner, domain, zone, RRSet). In section 5.1, corrected typo (its domain -> other domains) In section 5.2.2, spelt out that subsequent DNS query should not be made. In section 5.3.3, spelt out where this contrasts with terminal rule processing. Made text more precise - (used -> provisioned using) In section 6.2, spelt out why EDNS0 is needed, corrected typo (mesages -> messages), and refined which servers need to support EDNS0 On request, removed un-cited references. Changes in edns0-02 ---- Re-phrased to be more precise - we are talking about the size option of EDNS0, not just the EDNS0 framework Added recommended sizes for this option. (These are in keeping with section 6.2 of the experiences draft). ------------------ In summary, the goal is to progress the EDNS0 draft if this can be done quickly, and to replace the current text on EDNS0 within the experiences draft with a reference to the EDNS0 document. Question for the WG: The EDNS0 document discusses the impact of fragmentation on DNS processing for ENUM. Is this appropriate, given that the audience is likely to be ENUM implementers who do not have complete familiarity with the more complex issues of DNS? The experiences draft has some descriptive text in section 6 explaining why the implementer must implement the recommendations in RFC2181. This was added as ENUM implementers may not be familiar with all of the DNS documents. Given the intended audience for this document, should this be retained, or instead be replaced with a single sentence referring the reader to 2181? (Something like - "For further guidance see RFC 2181 as that covers other aspects of DNS operation that are significant for ENUM processing. ".) all the best, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Jul 09 07:19:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzXK7-0006Wm-In; Sun, 09 Jul 2006 07:19:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzXK5-0006Wh-Hs for enum@ietf.org; Sun, 09 Jul 2006 07:19:37 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzXK5-0008OX-4Y for enum@ietf.org; Sun, 09 Jul 2006 07:19:37 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 09 Jul 2006 04:19:37 -0700 X-IronPort-AV: i="4.06,220,1149490800"; d="scan'208"; a="327970769:sNHT33244838" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k69BJa5T001367 for ; Sun, 9 Jul 2006 04:19:36 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k69BJasT016261 for ; Sun, 9 Jul 2006 04:19:36 -0700 (PDT) Received: from [127.0.0.1] (ssh-ams-1.cisco.com [144.254.226.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k69BDn9Q001233 for ; Sun, 9 Jul 2006 04:13:50 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <187818D2-7193-4B9F-963A-4E87D10F5A58@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF ENUM WG From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Sun, 9 Jul 2006 07:19:33 -0400 X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-3.cisco.com; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=4621; t=1152443976; x=1153307976; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:ENUM=20Next=20Generation; X=v=3Dcisco.com=3B=20h=3DFpfnJuBTKu3lE8GYSWIdTqYvHYk=3D; b=kR4lrtK6RAOZu0QNRVxqn1aYtfbDFJo4OPlaaA3bz+padwYMw2gjsQwYhm0iw+aTdNaPbN8K 1HxuHwPBFjsyvEs0JPn3WHzHB7nFQDKNubumooirC66RXFv2tjMkOEzE; X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Subject: [Enum] ENUM Next Generation X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org In paris I floated some ideas with some people, including non-enum people, DNS people etc. This idea tries to solve two problems: (1) When looking for URIs with ENUM today we use NAPTR records that imply one get back a very large resource record set. When signing this with DNSSEC, the size of the set will grow even more. This even though we when issuing the query already know what service field(s) we are interested in. (2) In infrastructure ENUM, I think one of the requirements that weighs in the heaviest is the ability for the service provider of the service the URI refer to can edit the zone where the record is stored that holds the URI. I have also walked through the issues people have created tickets for (and you will see the list at the ENUM meeting this week), and see that many are related to NAPTR resolution, which in turn is connected to (2) above. To understand some of the thinking behind this proposal, it might be interesting to read draft-iab-dns-choices-03.txt that I am the editor of. If I could turn the clock back to 1997 when I started looking at what ended up being ENUM, I think I would have designed it a little bit different. Not much. And the question is whether we can do anything about it. If you look at how NAPTR was defined from the beginning, it was in "cooperation" with the SRV record. The NAPTR and SRV solve two different things: - NAPTR is used when you want to know what services exists for a domain. - SRV is used when you know the service and domain and want to know more. With ENUM we try to do both with the NAPTR alone. An architecturally better solution would be to do something more similar to the NAPTR+SRV thing. The NAPTR list what services exists, and the SRV give back detailed data. Issue is of course that the SRV RR Type today give back only hostname and port number part from the weight and order, and what we need is a full URI. What if we create a new RR Type that give back a URI? Example 1 (not completely good, but read on to example 2): Look for information about +46-8-1234. Look up NAPTR for 4.3.2.1.8.6.4.e164.arpa. Result might be (where "f" is a new random flag): "E2U+sip" "f" _sip._enum.4.3.2.1.8.6.4.sipprovider.net. "E2U+smtp" "f" _sip._enum.4.3.2.1.8.6.4.emailprovider.net. Then we issue a 2nd query depending on what we are looking for either of these two: _sip._enum.4.3.2.1.8.6.4.sipprovider.net. IN URI "sip: 081234@sipprovider.net" _sip._enum.4.3.2.1.8.6.4.emailprovider.net. IN URI "mailto: 081234@sipprovider.net" This of course does not create any ability to directly query for the URI resource record type if we only know the E.164, and on top of this, it is not backward compatible with user ENUM. Example 2: Look for information about +46-8-1234. Look up NAPTR for 4.3.2.1.8.6.4.e164.arpa. Result might be: "E2U+sip" "u" "!.*!sip:081234@sipprovider.net!" "E2U+smtp" "u" "!.*!mailto:081234@emailprovider.net!" Then we issue a 2nd query depending on what we are looking for either of these two: _sip._enum.4.3.2.1.8.6.4.e164.arpa. IN URI "sip:081234@sipprovider.net" _smtp._enum.4.3.2.1.8.6.4.emailprovider.net. IN URI "mailto: 081234@sipprovider.net" Note what we do in the 2nd case. We keep the NAPTR as defined, but we also create the new URI records that are in subdomains of the zone where the user ENUM records are stored. The name of the subdomains are the service fields in the _enum subdomain. That way, we can say that if you know what service field you are interested in, you can query directly for the URI resource record type. You get smaller RR Sets, and (a good thing for infrastructure ENUM I think) it is possible to do delegations from the zone that is today User ENUM to the service providers. I.e. if the zone for the E. 164 is held by a neutral party (just like the parent zone(s)), the delegation for the tel service field can be made to the carrier of record for the E.164 number. It is also possible to, in a similar way, delegate the email service field to the email service provider. Infrastructure ENUM can then be "first query for the URI record for the E.164, and if that fails, fall back to query for the NAPTR to see what other services exists". Now, what do you say? Should "RFC 3761 bis" include something like this and try to solve infrastructure ENUM and user enum at the same time? For how long do we have to store the URIs in the NAPTR? Patrik _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Jul 09 10:54:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzafS-0001oH-9R; Sun, 09 Jul 2006 10:53:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzafR-0001oC-Hv for enum@ietf.org; Sun, 09 Jul 2006 10:53:53 -0400 Received: from central.switch.ch ([130.59.11.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzafQ-0008Eh-7J for enum@ietf.org; Sun, 09 Jul 2006 10:53:53 -0400 Received: from machb.switch.ch ([130.59.6.129]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1FzafO-0005v8-00; Sun, 09 Jul 2006 16:53:50 +0200 Date: Sun, 9 Jul 2006 16:53:43 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] ENUM Next Generation In-Reply-To: <187818D2-7193-4B9F-963A-4E87D10F5A58@cisco.com> Message-ID: References: <187818D2-7193-4B9F-963A-4E87D10F5A58@cisco.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="98048-1941616486-1152456823=:18928" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: IETF ENUM WG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --98048-1941616486-1152456823=:18928 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Patrik Interesting ideas... Comments inline. On Sun, 9 Jul 2006, Patrik F=E4ltstr=F6m wrote: > Then we issue a 2nd query depending on what we are looking for either of= =20 > these two: > > _sip._enum.4.3.2.1.8.6.4.e164.arpa. IN URI "sip:081234@sipprovider.net" > > _smtp._enum.4.3.2.1.8.6.4.emailprovider.net. IN URI "mailto:081234@sippro= vider.net" could it be that this example (smtp) contains a typo? I would rather expect: _smtp._enum.4.3.2.1.8.6.4.e164.arpa. IN URI "mailto:081234@emailprovider.ne= t" Or did I miss anything? > and (a good thing for infrastructure ENUM I think) it is possible to=20 > do delegations from the zone that is today User ENUM to the service=20 > providers. I.e. if the zone for the E.164 is held by a neutral party (jus= t=20 > like the parent zone(s)), the delegation for the tel service field can be= =20 > made to the carrier of record for the E.164 number. Hmmm, this would involve, that the Tier-1 Registry (or some other=20 trusted party) needs to maintain the U-ENUM Zones, to ensure correct=20 delegations to the I-ENUM entries. Carriers put stronger requirements to (DNS) answering times and timeouts,= =20 as the call-setup time is crucial. Therefore no way, that a user can=20 operate his own nameservers. You could also not leave the U-ENUM zone maintainance to the carrier, as=20 this might be misused to hinder or control (in a negative sense) the=20 U-ENUM deployment. Anyways, IMHO this is not backward compatible to nowadays ENUM deployment. Furthermore this would also kind of mandate RFC 4114, Dynamic DNS updates= =20 or some other (possibly new) interface to change the content of the U-ENUM = Zones. > Now, what do you say? I like the idea to keep the zones small (packet size/EDNS0 discussions),=20 but I am not sure, whether this is a good way to combine U-ENUM and=20 I-ENUM. BTW: Could your idea have impact on block delegations or open numbering=20 plans? I haven't studied that through yet. cheers, Bernie --98048-1941616486-1152456823=:18928 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --98048-1941616486-1152456823=:18928-- From enum-bounces@ietf.org Sun Jul 09 11:27:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzbBx-0004bq-LV; Sun, 09 Jul 2006 11:27:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzbBw-0004XZ-Fn for enum@ietf.org; Sun, 09 Jul 2006 11:27:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzbBv-0005JP-UF for enum@ietf.org; Sun, 09 Jul 2006 11:27:28 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 09 Jul 2006 08:27:27 -0700 X-IronPort-AV: i="4.06,221,1149490800"; d="scan'208"; a="1836637831:sNHT33143340" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k69FRRbI008745; Sun, 9 Jul 2006 08:27:27 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k69FRRfr024183; Sun, 9 Jul 2006 08:27:27 -0700 (PDT) Received: from [127.0.0.1] (ssh-ams-1.cisco.com [144.254.226.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k69FLamb010710; Sun, 9 Jul 2006 08:21:40 -0700 In-Reply-To: References: <187818D2-7193-4B9F-963A-4E87D10F5A58@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4A0576C4-2C25-470F-86B0-E1691C274BD0@cisco.com> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] ENUM Next Generation Date: Sun, 9 Jul 2006 11:27:20 -0400 To: Bernie Hoeneisen X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-7.cisco.com; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3821; t=1152458847; x=1153322847; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:Re=3A=20[Enum]=20ENUM=20Next=20Generation; X=v=3Dcisco.com=3B=20h=3DeB2QgtpQGfFwckncjeCwqkUO1G4=3D; b=avyyIfQ8eXJEw6WGTUkvlppmZFi8mgnGmwOz6/wPruYJNurXLoB6tZxoEdNLM69DHb1N2TDL hwHlim8D2oQMBq5S2AKUsXF+lz5vys5e/htCYlCoMPn27qc8PpmuBIhX; X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: IETF ENUM WG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 9 jul 2006, at 10.53, Bernie Hoeneisen wrote: > On Sun, 9 Jul 2006, Patrik F=E4ltstr=F6m wrote: > >> Then we issue a 2nd query depending on what we are looking for =20 >> either of these two: >> >> _sip._enum.4.3.2.1.8.6.4.e164.arpa. IN URI "sip:=20 >> 081234@sipprovider.net" >> >> _smtp._enum.4.3.2.1.8.6.4.emailprovider.net. IN URI "mailto:=20 >> 081234@sipprovider.net" > > could it be that this example (smtp) contains a typo? > I would rather expect: > > _smtp._enum.4.3.2.1.8.6.4.e164.arpa. IN URI "mailto:=20 > 081234@emailprovider.net" > > Or did I miss anything? You are correct. This was a typo. >> and (a good thing for infrastructure ENUM I think) it is possible =20 >> to do delegations from the zone that is today User ENUM to the =20 >> service providers. I.e. if the zone for the E.164 is held by a =20 >> neutral party (just like the parent zone(s)), the delegation for =20 >> the tel service field can be made to the carrier of record for the =20= >> E.164 number. > > Hmmm, this would involve, that the Tier-1 Registry (or some other =20 > trusted party) needs to maintain the U-ENUM Zones, to ensure =20 > correct delegations to the I-ENUM entries. Yes. > Carriers put stronger requirements to (DNS) answering times and =20 > timeouts, as the call-setup time is crucial. This is what they claim. Have you tried to set up a phone call across =20= the globe to see what the call setup time in reality is, or for that =20 matter a GSM call? If you get lower time than 5 seconds you are lucky. > Therefore no way, that a user can operate his own nameservers. Why not? And by the way, I do not see these operational constraints =20 be a problem that have anything to do with the design of the =20 protocol, so I want to leave those things out. > You could also not leave the U-ENUM zone maintainance to the =20 > carrier, as this might be misused to hinder or control (in a =20 > negative sense) the U-ENUM deployment. It could be left with whoever is "an approved ENUM zone maintainer". =20 Remember that in more and more TLDs you have to be "an approved DNS =20 provider" to have NS records point to you. I do not think that is a =20 good path the DNS community is on, but it is happening. > Anyways, IMHO this is not backward compatible to nowadays ENUM =20 > deployment. Why not? > Furthermore this would also kind of mandate RFC 4114, Dynamic DNS =20 > updates or some other (possibly new) interface to change the =20 > content of the U-ENUM Zones. How the zones are changed is up to the zone maintainer. But yes, =20 dynamic update might be one way of doing it, even though with normal =20 implementations of dynamic update you can only manage the =20 authentication and authorization on the triple class, type, owner, =20 which imply whoever can change one NAPTR will be able to change all =20 of them. This is why I think storing the NAPTR the way we do today in User =20 ENUM is possibly a bad idea. Better to move to what I hear call "Next =20= Generation ENUM" that can support both infrastructure ENUM and User =20 ENUM (and on top of this infrastructure ENUM for any service and not =20 only the telephony. >> Now, what do you say? > > I like the idea to keep the zones small (packet size/EDNS0 =20 > discussions), but I am not sure, whether this is a good way to =20 > combine U-ENUM and I-ENUM. Ok. Good point. > BTW: Could your idea have impact on block delegations or open =20 > numbering plans? I haven't studied that through yet. Possibly. I have not thought so much about it (yet). What I am =20 removing is the ability to have regular expressions and rewrites in =20 the URI record, and this is possibly something that is used by some =20 people. Patrik _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Jul 09 12:18:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzbz6-0008LA-Tx; Sun, 09 Jul 2006 12:18:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzbz5-0008J2-Uu for enum@ietf.org; Sun, 09 Jul 2006 12:18:15 -0400 Received: from central.switch.ch ([130.59.11.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzbz4-00028c-LS for enum@ietf.org; Sun, 09 Jul 2006 12:18:15 -0400 Received: from machb.switch.ch ([130.59.6.129]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1Fzbz3-0000ul-00; Sun, 09 Jul 2006 18:18:13 +0200 Date: Sun, 9 Jul 2006 18:18:04 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] ENUM Next Generation In-Reply-To: <4A0576C4-2C25-470F-86B0-E1691C274BD0@cisco.com> Message-ID: References: <187818D2-7193-4B9F-963A-4E87D10F5A58@cisco.com> <4A0576C4-2C25-470F-86B0-E1691C274BD0@cisco.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="98048-352009105-1152461884=:18928" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF ENUM WG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --98048-352009105-1152461884=:18928 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Patrik On Sun, 9 Jul 2006, Patrik F=E4ltstr=F6m wrote: >> Therefore no way, that a user can operate his own nameservers. > > Why not? As said, the maintainer of the ENUM zone must be a trusted party with this= =20 approach, cause the maintainer of the DNS zone also affects the carrier's= =20 operations (e.g. in case of misconfigurations). He has to ensure that the= =20 NS records pointing the the I-ENUM zones are correct at any time and=20 guarantee a high level of q.o.s. Looking at nameserver setups made by the= =20 (end)users themselves (as we see such occasionally at customers of the=20 =2Ech/.li and the 1.4.e164.arpa Registry) do not give me a lot of=20 confidence that carrier requirements would be fulfilled in every case. > And by the way, I do not see these operational constraints be a=20 > problem that have anything to do with the design of the protocol, so I wa= nt=20 > to leave those things out. I am not sure, whether those can be left out completely. >> Anyways, IMHO this is not backward compatible to nowadays ENUM deploymen= t. > > Why not? Maybe I should have been more precise here. Technically it probabely is=20 backward compatible. I was thinking more about administrative and=20 provisioning issues resulting from the fact, that the choice of namesevers= =20 would be limited with this approach. cheers, Bernie --98048-352009105-1152461884=:18928 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --98048-352009105-1152461884=:18928-- From enum-bounces@ietf.org Mon Jul 10 00:48:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzngq-0000UT-Ox; Mon, 10 Jul 2006 00:48:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzngp-0000UM-MF for enum@ietf.org; Mon, 10 Jul 2006 00:48:11 -0400 Received: from mail.flextronicssoftware.com ([203.187.132.2] helo=delta.hssblr.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FznFB-0004kX-In for enum@ietf.org; Mon, 10 Jul 2006 00:19:39 -0400 Received: from pragati.blr.hss.hns.com ([10.203.193.22]) by delta.hssblr.co.in (8.13.6/8.13.6) with ESMTP id k6A4JUDI007096 for ; Mon, 10 Jul 2006 09:49:34 +0530 To: enum@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Prashant.Murthy@flextronicssoftware.com Date: Mon, 10 Jul 2006 09:47:34 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5.5|November 30, 2005) at 07/10/2006 09:47:20 AM, Serialize complete at 07/10/2006 09:47:20 AM X-Spam-Score: 0.7 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Enum] Processing of 'Additional Information Section' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0184482616==" Errors-To: enum-bounces@ietf.org This is a multipart message in MIME format. --===============0184482616== Content-Type: multipart/alternative; boundary="=_alternative 0017C0C7652571A7_=" This is a multipart message in MIME format. --=_alternative 0017C0C7652571A7_= Content-Type: text/plain; charset="US-ASCII" Hi, I have a question on the use of 'Additional Information Section' of a given DNS response. RFC 3761 say that the clients are encouraged to check for additional information present in the response. When we query for an e164 number, we will get AORs associated with different services. In case the client supports that service, it will fetch contacts and perform SRV/A lookup. My question is what additional information the NAPTR response contain? Do the current DNS servers support additional information section? Can anyone suggest a place where I can get a detailed information about the processing of additional information section ? Whether it is important to process this additional information section? Regards, Prashant *********************** FSS-Private *********************** --=_alternative 0017C0C7652571A7_= Content-Type: text/html; charset="US-ASCII"
Hi,

I have a question on the use of 'Additional Information Section' of a given DNS response.

RFC 3761 say that the clients are encouraged to check for additional information present in the response.

When we query for an e164 number, we will get AORs associated with different services. In case the client supports that service, it will fetch contacts and perform SRV/A lookup. My question is what additional information the NAPTR response contain? Do the current DNS servers support additional information section? Can anyone suggest a place where I can get a detailed information about the processing of additional information section ? Whether it is important to process this additional information section?

Regards,
Prashant

***********************  FSS-Private   *********************** --=_alternative 0017C0C7652571A7_=-- --===============0184482616== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0184482616==-- From enum-bounces@ietf.org Wed Jul 12 13:18:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iMF-0006JE-K4; Wed, 12 Jul 2006 13:18:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iME-0006Go-An for enum@ietf.org; Wed, 12 Jul 2006 13:18:42 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0i8i-0006aE-0j for enum@ietf.org; Wed, 12 Jul 2006 13:04:45 -0400 Received: from [132.219.8.184] (softdnserr [::ffff:132.219.8.184]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 12 Jul 2006 19:04:37 +0200 id 0007C07C.44B52BA5.00006D9A Message-ID: <44B52B86.4060909@enum.at> Date: Wed, 12 Jul 2006 19:04:06 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Enum] request for input on enumservices guide X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org All, as indicated in the ENUM session on monday, i'd appreciate input on the enumservices guide / template draft: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-01.txt Again, any time that we invest into definitions here will save us time on any future Enumservice registration that uses that template, because if we eg. agree on a convention for subtyping, we won't have to discuss that again for each service. Same applies for the Security/IANA Considerations. assumptions: - we want that to be an informational - hence, we don't want that to be a normative reference for the actual registrations - therefore, all normative stuff needs to be included in the XML template - however, clarifications of the stuff in the XML template should go into the draft document - it should be explained why we chose a certain approach, and when to divert from that. potential topics to be worked on: - choosing type names - choosing subtype names - what to achieve with subtypes - security considerations, pii considerations I'd appreciate if there would be a few text proposals. thanks, Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 13 11:16:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12vA-0007GS-GU; Thu, 13 Jul 2006 11:16:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12v8-0007GM-Pd for enum@ietf.org; Thu, 13 Jul 2006 11:16:06 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12v7-0000i6-Cr for enum@ietf.org; Thu, 13 Jul 2006 11:16:06 -0400 Received: from RSHOCKEYLTXP (h16d0-net84db.lab.risq.net [132.219.22.208] (may be forged)) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k6DFGMvP025867 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 13 Jul 2006 08:16:25 -0700 From: "Richard Shockey" To: Date: Thu, 13 Jul 2006 11:15:54 -0400 Message-ID: <018701c6a68f$3e9cdec0$d016db84@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcamjzwfCz1CDf2+TOCZ0/3Glcplrw== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= , "'Peterson, Jon'" Subject: [Enum] ENUM Working Group last call for document draft-ietf-enum-validation-token-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Title : ENUM Validation Token Format Definition Author(s) : O. Lendl Filename : draft-ietf-enum-validation-token-02.txt Pages : 16 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-token-02.txt This document has been extensively discussed in the WG in 2005 and 2006 The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for 2 weeks or so from today July 13 until at least July 31 though we can modify that if new issues come up. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 14 14:52:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Sm4-0001QQ-0c; Fri, 14 Jul 2006 14:52:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Sm2-0001QB-LP for enum@ietf.org; Fri, 14 Jul 2006 14:52:26 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Sm1-0002ng-BE for enum@ietf.org; Fri, 14 Jul 2006 14:52:26 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 14 Jul 2006 11:52:24 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6EIqOoj017159; Fri, 14 Jul 2006 11:52:24 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6EIqO2D026247; Fri, 14 Jul 2006 11:52:24 -0700 (PDT) Received: from [127.0.0.1] (ssh-ams-1.cisco.com [144.254.226.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k6EIkIfF012893; Fri, 14 Jul 2006 11:46:19 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1BD38415-215A-4D19-8C59-A76ED993FA08@cisco.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] Processing of 'Additional Information Section' Date: Fri, 14 Jul 2006 14:52:21 -0400 To: Prashant.Murthy@flextronicssoftware.com X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-4.cisco.com; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2986; t=1152903144; x=1153767144; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:Re=3A=20[Enum]=20Processing=20of=20'Additional=20Information=20Section'; X=v=3Dcisco.com=3B=20h=3DucT7z12ej/N0QxV0x0HUC9cGtJc=3D; b=pKLcO77v0/c2oEVgO2VBnyxP6tJBYlAPGbpunPlndQOm3B+yeHQH3bt3ht8tGJfUf0mw2hCn NK2XAKgb/maKgQpAvR6es/ZHloWYmgV0HUBUsTD4Xi14kJ2DlvKwEAM5; X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 10 jul 2006, at 00.17, Prashant.Murthy@flextronicssoftware.com wrote: > I have a question on the use of 'Additional Information Section' of a > given DNS response. > > RFC 3761 say that the clients are encouraged to check for additional > information present in the response. > > When we query for an e164 number, we will get AORs associated with > different services. In case the client supports that service, it will > fetch contacts and perform SRV/A lookup. My question is what > additional > information the NAPTR response contain? Depends on what the server choose to put there. For "normal" use of NAPTR+SRV, it normally include the SRV records. Here is one example: pingu>dig outgoingproxy.yxa.frobbit.se. naptr ; <<>> DiG 9.2.2 <<>> outgoingproxy.yxa.frobbit.se. naptr ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60887 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 5 ;; QUESTION SECTION: ;outgoingproxy.yxa.frobbit.se. IN NAPTR ;; ANSWER SECTION: outgoingproxy.yxa.frobbit.se. 900 IN NAPTR 10 0 "s" "SIP+D2T" "" _sip._tcp.outgoingproxy.yxa.frobbit.se. outgoingproxy.yxa.frobbit.se. 900 IN NAPTR 10 0 "s" "SIP+D2U" "" _sip._udp.outgoingproxy.yxa.frobbit.se. outgoingproxy.yxa.frobbit.se. 900 IN NAPTR 10 0 "s" "SIPS+D2T" "" _sips._tcp.outgoingproxy.yxa.frobbit.se. ;; AUTHORITY SECTION: frobbit.se. 520 IN NS ns.cafax.se. frobbit.se. 520 IN NS ns1.frobbit.se. ;; ADDITIONAL SECTION: sip.frobbit.se. 900 IN A 193.109.175.117 ns1.frobbit.se. 877 IN A 66.125.125.88 _sip._tcp.outgoingproxy.yxa.frobbit.se. 900 IN SRV 0 0 5066 sip.frobbit.se. _sip._udp.outgoingproxy.yxa.frobbit.se. 900 IN SRV 0 0 5066 sip.frobbit.se. _sips._tcp.outgoingproxy.yxa.frobbit.se. 900 IN SRV 0 0 5067 sip.frobbit.se. ;; Query time: 124 msec ;; SERVER: 132.219.0.11#53(132.219.0.11) ;; WHEN: Fri Jul 14 14:45:33 2006 ;; MSG SIZE rcvd: 428 > Do the current DNS servers support > additional information section? Absolutely. > Can anyone suggest a place where I can get > a detailed information about the processing of additional information > section ? It is up to you as a client to use that data if you want to. > Whether it is important to process this additional information > section? It minimizes the number of queries sent to the DNS. On the other hand, you should not blindly trust what is in there (because it might be fake data, and if you cache it you might get so called cache posioning), just like you should/can not trust any data from DNS if it is not the case you use DNSSEC, in what case both answer and additional data in the response can be verified. Description of the various sections of queries and responses for DNS in laid out in any book on DNS. Patrik _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jul 17 06:30:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2QMi-00005Z-UX; Mon, 17 Jul 2006 06:30:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2QMi-00005T-0j for enum@ietf.org; Mon, 17 Jul 2006 06:30:16 -0400 Received: from mail.ficora.fi ([194.100.96.25] helo=portti1.ficora.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2QMf-0001yq-Gr for enum@ietf.org; Mon, 17 Jul 2006 06:30:15 -0400 Received: from POSTI.laru.local ([10.1.0.10]) by portti1.ficora.fi with InterScan Messaging Security Suite; Mon, 17 Jul 2006 13:42:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] ENUM Working Group last call for documentdraft-ietf-enum-validation-token-01.txt Date: Mon, 17 Jul 2006 13:30:48 +0300 Message-ID: <07BC6C0D40216E44A34BE6701694FE86038B46DD@POSTI.laru.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] ENUM Working Group last call for documentdraft-ietf-enum-validation-token-01.txt Thread-Index: AcamjzwfCz1CDf2+TOCZ0/3GlcplrwC+7iew From: "Nieminen Klaus" To: X-Spam-Score: 0.6 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi all, I have one minor issue that I believe to be valid for most current ENUM = IDs. The old E.164 Recommendation has been replaced by a new one E.164 = (02/05.=20 For more details see: http://www.itu.int/rec/T-REC-E.164/en It's not critical, but I think we should start using the latest version. regards, - Klaus - -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: 13. hein=E4kuuta 2006 18:16 To: enum@ietf.org Cc: 'Cullen Jennings'; 'Patrik F=E4ltstr=F6m'; 'Peterson, Jon' Subject: [Enum] ENUM Working Group last call for = documentdraft-ietf-enum-validation-token-01.txt =20 Title : ENUM Validation Token Format Definition Author(s) : O. Lendl Filename : draft-ietf-enum-validation-token-02.txt Pages : 16 =09 =09 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-token-02.t= xt This document has been extensively discussed in the WG in 2005 and 2006 The intent of the last call is to solicit comments before submitting the = ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now = or forever hold your peace" in case there are fundamental objections = which have not gotten previous or adequate discussion, or minor errors = which need correction. Work group last call will extend for 2 weeks or so from today July 13 = until at least July 31 though we can modify that if new issues come up. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org = sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 = 703.593.2683 = _______________________________________________ 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 enum-bounces@ietf.org Mon Jul 17 23:02:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2frE-0007o3-Ph; Mon, 17 Jul 2006 23:02:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2frD-0007nM-55 for enum@ietf.org; Mon, 17 Jul 2006 23:02:47 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2frA-0002rO-NH for enum@ietf.org; Mon, 17 Jul 2006 23:02:47 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k6I32vGw032436 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 17 Jul 2006 20:02:59 -0700 From: "Richard Shockey" To: Date: Mon, 17 Jul 2006 23:02:28 -0400 Message-ID: <005901c6aa16$9c24aed0$23f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 thread-index: AcaqFpqvN9YenI23TdWGhb6+eg63Yg== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= , "'Peterson, Jon'" Subject: [Enum] ENUM Working Group Last call for document draft-ietf-enum-im-service-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Title : A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services Author(s) : R. Mahy Filename : draft-ietf-enum-im-service-01.txt Pages : 5 Date : 2006-6-22 This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs in ENUM. http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-01.txt The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten, previous or adequate discussion, or minor errors which need correction. Work group last call will extend from today July 17 until at August 14 to insure a through and proper review though we can modify that if new issues come up. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jul 17 23:12:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2g0v-00064R-JQ; Mon, 17 Jul 2006 23:12:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2g0u-00064J-Ay for enum@ietf.org; Mon, 17 Jul 2006 23:12:48 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2g0s-0004H8-Um for enum@ietf.org; Mon, 17 Jul 2006 23:12:48 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k6I3D2Hq001450 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 17 Jul 2006 20:13:04 -0700 From: "Richard Shockey" To: Date: Mon, 17 Jul 2006 23:12:32 -0400 Message-ID: <000601c6aa18$0413c7a0$23f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaqGAJLNfWlX+qNTGSuHne1ju0khA== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= , "'Peterson, Jon'" Subject: [Enum] ENUM WG Last Call for draft-ietf-enum-calendar-service-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Title : A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services Author(s) : R. Mahy Filename : draft-ietf-enum-calendar-service-01.txt Pages : 6 Date : 2006-7-6 This document registers a Telephone Number Mapping (ENUM) service for Internet Calendaring Services. Specifically, this document focuses on provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-01.txt The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend from today July 17 until at August 14 to insure a through and proper review though we can modify that if new issues come up. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 18 00:44:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2hRc-0003ah-81; Tue, 18 Jul 2006 00:44:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2hRb-0003ac-0x for enum@ietf.org; Tue, 18 Jul 2006 00:44:27 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2hRY-00031t-Ka for enum@ietf.org; Tue, 18 Jul 2006 00:44:27 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k6I4iNBV011009 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 17 Jul 2006 21:44:32 -0700 From: "Richard Shockey" To: Date: Tue, 18 Jul 2006 00:43:39 -0400 Message-ID: <001701c6aa24$c3e558d0$23f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaqJLyHPq8+vttsRiOdnqxp6AmF2Q== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= , "'Peterson, Jon'" Subject: [Enum] oops..ENUM Working Group Last call for documentdraft-ietf-enum-im-service-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Wrong URL .. Title : A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services Author(s) : R. Mahy Filename : draft-ietf-enum-im-service-01.txt Pages : 5 Date : 2006-6-22 This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs in ENUM. http://www.ietf.org/internet-drafts/draft-ietf-enum-im-service-01.txt The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten, previous or adequate discussion, or minor errors which need correction. Work group last call will extend from today July 17 until at August 14 to insure a through and proper review though we can modify that if new issues come up. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 25 15:50:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SvG-00079O-Ge; Tue, 25 Jul 2006 15:50:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Sux-0006kV-CR; Tue, 25 Jul 2006 15:50:11 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Suw-0007mg-3z; Tue, 25 Jul 2006 15:50:11 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6PJo1p0005465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 19:50:10 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G5Sun-0002iK-Jn; Tue, 25 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 25 Jul 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-cnam-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by oak.neustar.com id k6PJo1p0005465 A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Telephone Number Mapping Working Group o= f the IETF. Title : IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA=20 Registration for Media type =91application/cnam Author(s) : R. Shockey, et al. Filename : draft-ietf-enum-cnam-02.txt Pages : 13 Date : 2006-7-25 =09 This document registers the Enumservice =91pstn=92 and the compound=20 subtype =91cnam=92 using the URI scheme =91data:=92, as per the IANA=20 registration process defined in the ENUM specification, RFC 3761 and=20 creates a new media type application/cnam.. =20 =20 This data is used to facilitate the transfer of Calling Name Delivery=20 (CNAM) data for calls that originate on the Public Switched Telephone=20 Network (PSTN) that may be displayed on VoIP or other Real-time=20 Client User Agents (CUA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-02.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of th= e message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-cnam-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-cnam-02.txt". =09 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. =09 =09 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: <2006-7-25121518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-cnam-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-cnam-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-25121518.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart--