From enum-bounces@ietf.org Fri Sep 01 11:51:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJBHI-0006iC-Gn; Fri, 01 Sep 2006 11:49:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJBHH-0006i4-5y for enum@ietf.org; Fri, 01 Sep 2006 11:49:55 -0400 Received: from [61.16.168.135] (helo=delta.hss.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJBHF-0006Ba-7u for enum@ietf.org; Fri, 01 Sep 2006 11:49:55 -0400 Received: from pragati.blr.hss.hns.com ([10.203.193.22]) by delta.hss.co.in (8.13.6/8.13.6) with ESMTP id k81Fno7P010631 for ; Fri, 1 Sep 2006 21:19:50 +0530 MIME-Version: 1.0 To: enum@ietf.org X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: vikram.agrawal@flextronicssoftware.com Date: Fri, 1 Sep 2006 21:18:08 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5.5|November 30, 2005) at 09/01/2006 09:14:10 PM, Serialize complete at 09/01/2006 09:14:10 PM X-Spam-Score: 0.8 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [Enum] Regular Expression Pattern 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="===============1397919838==" Errors-To: enum-bounces@ietf.org This is a multipart message in MIME format. --===============1397919838== Content-Type: multipart/alternative; boundary="=_alternative 0056F4BE652571DC_=" This is a multipart message in MIME format. --=_alternative 0056F4BE652571DC_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGksDQogSSBoYXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSBSZWd1bGFyIEV4cHJlc3Npb24g ZmllbGQgaW4gdGhlIE5BUFRSIA0KUmVjb3JkIHJlY2VpdmVkIGFzIGEgcmVzcG9uc2UgdG8gdGhl IEROUyBxdWVyeS4NCiANClRoZSBSZWd1bGFyIEV4cHJlc3Npb24gaXMgYWx3YXlzIGFwcGxpZWQg dG8gdGhlIEFVUy4gDQpUaGUgQVVTIGZvciBhbiBFbnVtIHF1ZXJ5IGlzIGNvbnZlcnRlZCBpbnRv IGEgIGRvbWFpbiBuYW1lIGFjY29yZGluZyB0byANCnRoZSBBbGdvcml0aG0gc3BlY2lmaWVkIGZv ciBjb252ZXJ0aW5nIHRoZSBlMTY0IG51bWJlciAgaW50byBhIGRvbWFpbiBuYW1lIA0KKEFzIHBl ciBSRkMgMzc2MSkuDQpOb3cgLHNheSB3ZSBxdWVyaWVkIGZvciBOQVBUUiByZWNvcmRzIGFmdGVy IGNvbnZlcnRpbmcgYSBnbG9iYWwgZTE2NCANCm51bWJlciBpbnRvIGEgZG9tYWluIG5hbWUgKHVz aW5nIHRoZSB0b3AgbGV2ZWwgZG9tYWluIG5hbWUgLSBlMTY0LmFycGEpLiANCldoYXQgdGhlbiBp cyB0aGUgbmVlZCBmb3IgdGhlIFJlZ3VsYXIgRXhwcmVzc2lvbiBwYXR0ZXJuID8gIENhbiB0aGUg DQpwYXR0ZXJuIHBhcnQgIG9mIHRoZSBSZWd1bGFyIGV4cHJlc3Npb24gYmUgZml4ZWQgYXMgIl4u KiQiIHdoaWNoIHdvdWxkIA0KbWVhbiBpdCBhcHBsaWVzIHRvIHRoZSBlbnRpcmUgc3RyaW5nIGku ZS4gdGhlIGVudGlyZSBEb21haW4gTmFtZSB0aGF0IHdhcyANCnF1ZXJpZWQgZm9yLg0KIFNwZWNp YWxseSBpbiBjYXNlIHdoZW4gTm9uIC0gdGVybWluYWwgcmVjb3JkcyBhcmUgbm90IGhhbmRsZWQg LCB3b3VsZCBhbnkgDQpkaWZmZXJlbnQgcGF0dGVybiBiZSBhdCBhbGwgcmVxdWlyZWQuDQoNCkFs c28gY2FuIGEgdGVybWluYWwgTkFQVFIgcmVjb3JkIGhhdmUgYSBSZWd1bGFyIEV4cHJlc3Npb24g cGF0dGVybiBvdGhlciANCnRoYW4gYXMgbWVudGlvbmVkIGkuZS4gIl4uKiQiDQoNCg0KDQoNCg0K DQoNCiAgUmVnYXJkcywNCiAgIFZpa3JhbQ0KIkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBw cm9wcmlldGFyeSB0byBGbGV4dHJvbmljcyBTb2Z0d2FyZSBTeXN0ZW1zIChGU1MpIGFuZCBpcyBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQg aXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBp bmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkg cHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5h dG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5 b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJpdGVkIGZyb20gdXNp bmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlz IG1lc3NhZ2UuIEZTUyBhY2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvciAKbG9zcyBvciBkYW1h Z2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGJ5 IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9tIHZpcnVzLiIK --=_alternative 0056F4BE652571DC_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhpLDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7SSBoYXZlIGEgcXVlc3Rpb24g cmVnYXJkaW5nIHRoZQ0KUmVndWxhciBFeHByZXNzaW9uIGZpZWxkIGluIHRoZSBOQVBUUiBSZWNv cmQgcmVjZWl2ZWQgYXMgYSByZXNwb25zZSB0bw0KdGhlIEROUyBxdWVyeS48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NClRoZSBSZWd1bGFyIEV4 cHJlc3Npb24gaXMgYWx3YXlzIGFwcGxpZWQgdG8gdGhlIEFVUy4gPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgQVVTIGZvciBhbiBFbnVtIHF1ZXJ5IGlzIGNv bnZlcnRlZA0KaW50byBhICZuYnNwO2RvbWFpbiBuYW1lIGFjY29yZGluZyB0byB0aGUgQWxnb3Jp dGhtIHNwZWNpZmllZCBmb3IgY29udmVydGluZw0KdGhlIGUxNjQgbnVtYmVyICZuYnNwO2ludG8g YSBkb21haW4gbmFtZSAoQXMgcGVyIFJGQyAzNzYxKS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPk5vdyAsc2F5IHdlIHF1ZXJpZWQgZm9yIE5BUFRSIHJlY29yZHMN CmFmdGVyIGNvbnZlcnRpbmcgYSBnbG9iYWwgZTE2NCBudW1iZXIgaW50byBhIGRvbWFpbiBuYW1l ICh1c2luZyB0aGUgdG9wDQpsZXZlbCBkb21haW4gbmFtZSAtIGUxNjQuYXJwYSkuIFdoYXQgdGhl biBpcyB0aGUgbmVlZCBmb3IgdGhlIFJlZ3VsYXIgRXhwcmVzc2lvbg0KcGF0dGVybiA/ICZuYnNw O0NhbiB0aGUgcGF0dGVybiBwYXJ0ICZuYnNwO29mIHRoZSBSZWd1bGFyIGV4cHJlc3Npb24gYmUN CmZpeGVkIGFzICZxdW90O14uKiQmcXVvdDsgd2hpY2ggd291bGQgbWVhbiBpdCBhcHBsaWVzIHRv IHRoZSBlbnRpcmUgc3RyaW5nDQppLmUuIHRoZSBlbnRpcmUgRG9tYWluIE5hbWUgdGhhdCB3YXMg cXVlcmllZCBmb3IuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDtTcGVjaWFsbHkgaW4gY2FzZSB3aGVuIE5vbiAtIHRlcm1pbmFsDQpyZWNvcmRzIGFyZSBu b3QgaGFuZGxlZCAsIHdvdWxkIGFueSBkaWZmZXJlbnQgcGF0dGVybiBiZSBhdCBhbGwgcmVxdWly ZWQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BbHNv IGNhbiBhIHRlcm1pbmFsIE5BUFRSIHJlY29yZCBoYXZlDQphIFJlZ3VsYXIgRXhwcmVzc2lvbiBw YXR0ZXJuIG90aGVyIHRoYW4gYXMgbWVudGlvbmVkIGkuZS4gJnF1b3Q7Xi4qJCZxdW90OzwvZm9u dD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KICZuYnNwO1JlZ2FyZHMsPGJyPg0KICZuYnNwOyBWaWty YW08L2ZvbnQ+DQo8dGFibGU+PHRyPjx0ZCBiZ2NvbG9yPSNmZmZmZmY+PGZvbnQgY29sb3I9IzAw MDAwMD48cHJlPiJESVNDTEFJTUVSOiBUaGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRhcnkgdG8gRmxl eHRyb25pY3MgU29mdHdhcmUgU3lzdGVtcyAoRlNTKSBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgdXNlIG9mIAp0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQg bWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNo b3VsZCBub3QgYmUgCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhh biBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNz YWdlIGluIGVycm9yLCAKcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0 aGF0IHlvdSBhcmUgc3RyaWN0bHkKcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRl cmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBGU1MgYWNj ZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0 aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1 ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iCjwvcHJlPjwvZm9udD48L3RkPjwvdHI+PC90YWJsZT4= --=_alternative 0056F4BE652571DC_=-- --===============1397919838== 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 --===============1397919838==-- From enum-bounces@ietf.org Sat Sep 02 03:50:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJQFP-0007vz-I5; Sat, 02 Sep 2006 03:48:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJQFN-0007vu-Ev for enum@ietf.org; Sat, 02 Sep 2006 03:48:57 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJQFM-0005kr-4n for enum@ietf.org; Sat, 02 Sep 2006 03:48:57 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id F1F091A36F; Sat, 2 Sep 2006 09:48:54 +0200 (CEST) Date: Sat, 2 Sep 2006 09:48:54 +0200 From: Otmar Lendl To: vikram.agrawal@flextronicssoftware.com Subject: Re: [Enum] Regular Expression Pattern Message-ID: <20060902074854.GA12939@nic.at> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 2006/09/01 17:09, vikram.agrawal@flextronicssoftware.com wrote: > > Now ,say we queried for NAPTR records after converting a global e164 > number into a domain name (using the top level domain name - e164.arpa). > What then is the need for the Regular Expression pattern ? Can the > pattern part of the Regular expression be fixed as "^.*$" which would > mean it applies to the entire string i.e. the entire Domain Name that was > queried for. > Specially in case when Non - terminal records are not handled , would any > different pattern be at all required. > > Also can a terminal NAPTR record have a Regular Expression pattern other > than as mentioned i.e. "^.*$" You're free to use "^.*$" to simply replace the number with a given URI. The regexp handling is extremely handy if you use DNS wildcards in your ENUM zone. Then one DNS record will match many different DNS queries and thus apply to many E.164 numbers. In order to have the resulting URI reflect the initial E.164 number, you have to use a more complex regexp. Consider e.g. +43 1 5056416. That's our office phone number here in Vienna. We're free to define extensions to that number, e.g. +43 1 5056416 33 is my desk phone. Austria uses an open numbering plan where the length of a number isn't fixed. We could thus use two single ENUM entries to cover all our needs: ; main number 6.6.1.4.6.5.0.5.1.3.4.e164.arpa. NAPTR 10 10 "u" "E2U+sip" "!^.*$!sip:office@enum.at!" . ; all extensions: *.6.6.1.4.6.5.0.5.1.3.4.e164.arpa. NAPTR 10 10 "u" "E2U+sip" "!^\\+4315056416(.*)$!sip:extension-\\1@enum.at!" . This maps +43 1 5056416 XY to sip:extension-XY@enum.at [The use of wildcards in the DNS is quite controversal, our experience with open numbering plans tells us that you can't avoid them, though.] > "DISCLAIMER: This message is proprietary to Flextronics Software > Systems (FSS) and is intended solely for the use of the individual to > whom it is addressed. [...] That's a creative way of writing "Our legal department is clueless." /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 05 10:01:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKbT9-0003ne-6x; Tue, 05 Sep 2006 10:00:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKbT7-0003nN-Mp for enum@ietf.org; Tue, 05 Sep 2006 10:00:01 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKbT6-0000dP-FT for enum@ietf.org; Tue, 05 Sep 2006 10:00:01 -0400 Received: from ([10.20.62.12]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.24076169; Tue, 05 Sep 2006 09:58:42 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 09:59:03 -0400 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] Regular Expression Pattern Date: Tue, 5 Sep 2006 09:59:02 -0400 Message-ID: <2D78B9A368A52344B12011D476BD4A8717D969@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Regular Expression Pattern Thread-Index: AcbN3rXpL6UxF6G7Q72sZgHGM2eYMADEW1Tw From: "Creighton, Tom" To: , X-OriginalArrivalTime: 05 Sep 2006 13:59:03.0242 (UTC) FILETIME=[71DA9AA0:01C6D0F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 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 Another application of the regexp and substitution expression (similar = to Otmar's example) would be if you are using the E.164 number in the = replacement section of the NAPTR record. This would allow you to = shorten your NAPTR record. AUS: +12153208617 NAPTR: 7.1.6.8.0.2.3.5.1.2.1.e164.arpa. NAPTR 10 10 "u"=20 "E2U+sip" "!^(.*)$!sip:\1@example.net!" . Rewritten URI: sip:+12153208617@example.net Regards, Tom ________________________________________ From: vikram.agrawal@flextronicssoftware.com = [mailto:vikram.agrawal@flextronicssoftware.com]=20 Sent: Friday, September 01, 2006 11:48 To: enum@ietf.org Subject: [Enum] Regular Expression Pattern Hi,=20 =A0I have a question regarding the Regular Expression field in the NAPTR = Record received as a response to the DNS query.=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The Regular Expression is always applied to the AUS.=20 The AUS for an Enum query is converted into a =A0domain name according = to the Algorithm specified for converting the e164 number =A0into a = domain name (As per RFC 3761).=20 Now ,say we queried for NAPTR records after converting a global e164 = number into a domain name (using the top level domain name - e164.arpa). = What then is the need for the Regular Expression pattern ? =A0Can the = pattern part =A0of the Regular expression be fixed as "^.*$" which would = mean it applies to the entire string i.e. the entire Domain Name that = was queried for.=20 =A0Specially in case when Non - terminal records are not handled , would = any different pattern be at all required.=20 Also can a terminal NAPTR record have a Regular Expression pattern other = than as mentioned i.e. "^.*$"=20 =A0Regards, =A0 Vikram=20 "DISCLAIMER: This message is proprietary to Flextronics Software Systems = (FSS) and is intended solely for the use of=20 the individual to whom it is addressed. It may contain privileged or = confidential information and should not be=20 circulated or used for any purpose other than for what it is intended. = If you have received this message in error,=20 please notify the originator immediately. If you are not the intended = recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of = this message. FSS accepts no responsibility for=20 loss or damage arising from the use of the information transmitted by = this email including damage from virus." _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 06 11:31:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKzKK-0004gx-Jq; Wed, 06 Sep 2006 11:28:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKzKG-0004dQ-CT for enum@ietf.org; Wed, 06 Sep 2006 11:28:28 -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 1GKz6P-0003dj-HQ for enum@ietf.org; Wed, 06 Sep 2006 11:14:10 -0400 Received: from [10.10.0.64] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 06 Sep 2006 17:13:56 +0200 id 0007C0C7.44FEE5B4.00006111 Message-ID: <44FEE55E.2020800@enum.at> Date: Wed, 06 Sep 2006 17:12:30 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Enum] thinking about an "location" Enumservice 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, i'm thinking about whether to start working on a "location" Enumservice (which would allow to refer from a phone number to the location of the associated device). I'm well aware of the work in GEOPRIV and ECRIT - however, some users (like hotels, tourist information, businesses eg.) might want to openly publish their location associated with a phone number, because their location can already be derived from eg. an web page etc. Actually, there would be at least two "indirect" ways of doing that: - using a "E2U+pres" Enumservice, which refers to a pres: URI, which in turn resolves to a PIDF document. That PIDF could be enhanced with PIDF-LO data. - using a "E2U+vcard:..." Enumservice, which points to a vCard instance with a GEO property - using a "LOC" resource record (RFC1876) [this would not be "full" ENUM] I'd appreciate comments whether we should a) explicitely recommend one of those solutions above, or b) draft a new "location" (or "geo") Enumservice? cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 06 12:39:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0Px-0002C4-US; Wed, 06 Sep 2006 12:38:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0Pv-0002BS-W7 for enum@ietf.org; Wed, 06 Sep 2006 12:38:23 -0400 Received: from wr-out-0506.google.com ([64.233.184.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL0Pt-0007t4-Ny for enum@ietf.org; Wed, 06 Sep 2006 12:38:23 -0400 Received: by wr-out-0506.google.com with SMTP id i4so836995wra for ; Wed, 06 Sep 2006 09:38:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H6NGzbhGA35OFkgRw3l3g1/x26fg+M8p/7HI6Rq2RDs0l0zFNURbkzJqo4k/4rhp/HNDt/fEQLqo/mUNr92omtnj9eveqBnW7VxfnQntUmitF4mU/rb/7uKklyIGYXy0mdY6LrtdfwhbGT0Tek3Qgau13Z93AbaLTtRNxgtpb/s= Received: by 10.90.79.6 with SMTP id c6mr672552agb; Wed, 06 Sep 2006 09:38:21 -0700 (PDT) Received: by 10.90.105.10 with HTTP; Wed, 6 Sep 2006 09:38:20 -0700 (PDT) Message-ID: Date: Wed, 6 Sep 2006 17:38:20 +0100 From: "Lee Dryburgh" To: "Alexander Mayrhofer" Subject: Re: [Enum] thinking about an "location" Enumservice In-Reply-To: <44FEE55E.2020800@enum.at> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44FEE55E.2020800@enum.at> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Hi Alex, I've already been drafting out an Enumservice which refers to a URI which resolves to a PIDF document for the purposes of both presence and location information. I would be more than happy to share what I have done so far. I had not been aware of RFC1876 before, so I had not considered LOC RR, besides they don't quite work as well for the applications that I have in mind. Regards Lee ---------- Forwarded message ---------- From: Alexander Mayrhofer Date: 06-Sep-2006 16:12 Subject: [Enum] thinking about an "location" Enumservice To: "enum@ietf.org" Hi, i'm thinking about whether to start working on a "location" Enumservice (which would allow to refer from a phone number to the location of the associated device). I'm well aware of the work in GEOPRIV and ECRIT - however, some users (like hotels, tourist information, businesses eg.) might want to openly publish their location associated with a phone number, because their location can already be derived from eg. an web page etc. Actually, there would be at least two "indirect" ways of doing that: - using a "E2U+pres" Enumservice, which refers to a pres: URI, which in turn resolves to a PIDF document. That PIDF could be enhanced with PIDF-LO data. - using a "E2U+vcard:..." Enumservice, which points to a vCard instance with a GEO property - using a "LOC" resource record (RFC1876) [this would not be "full" ENUM] I'd appreciate comments whether we should a) explicitely recommend one of those solutions above, or b) draft a new "location" (or "geo") Enumservice? cheers Alex _______________________________________________ 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 Wed Sep 06 12:57:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0iQ-0000SF-VU; Wed, 06 Sep 2006 12:57:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0iP-0000S1-LL for enum@ietf.org; Wed, 06 Sep 2006 12:57:29 -0400 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL0iN-0002bm-1k for enum@ietf.org; Wed, 06 Sep 2006 12:57:29 -0400 Received: by wr-out-0506.google.com with SMTP id i4so841759wra for ; Wed, 06 Sep 2006 09:57:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WU1rYh+VhMDuR9ROaddWZTPSj1H+jyw3gxrO0I7BTbxunNGJU5uOHDuCDUFwSuNG5QVwKXmH4nrbATmcl/vNoDttN9v0HhG6vthGk+vaIlkX5BNwqPRcodA5yhEo+ZLVJdILm7xxx+oB7/Q8htForH0RZgPoBn4lEoOrbhWuyU8= Received: by 10.90.51.17 with SMTP id y17mr2342209agy; Wed, 06 Sep 2006 09:57:26 -0700 (PDT) Received: by 10.90.105.10 with HTTP; Wed, 6 Sep 2006 09:57:26 -0700 (PDT) Message-ID: Date: Wed, 6 Sep 2006 17:57:26 +0100 From: "Lee Dryburgh" To: "Alexander Mayrhofer" Subject: Re: [Enum] thinking about an "location" Enumservice In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44FEE55E.2020800@enum.at> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 Additionally the other Enumservice that I have been drafting is one for XMPP's GEOLOC (http://www.jabber.org/jeps/jep-0080.html). The only concern I have is that we could run into many Enumservices. One for each means of providing location information. But I see no way around it and decided that the most important one's to cover first are PIDF+JEP-0080 (GEOLOC). For what I am working on, I don't think I am interested in anything beyond PIDF+JEP-0080. As regards ENUM E.164 owners who are physically static (hotels Etc. as you mention) then I would favour that the group follows your option b and drafts a new "location" Enumservice (which could even be automatically populated, so on reverse number lookup). Regards Lee On 06/09/06, Lee Dryburgh wrote: > Hi Alex, > > I've already been drafting out an Enumservice which refers to a URI > which resolves to a PIDF document for the purposes of both presence > and location information. > > I would be more than happy to share what I have done so far. > > I had not been aware of RFC1876 before, so I had not considered LOC > RR, besides they don't quite work as well for the applications that I > have in mind. > > Regards > > Lee > > ---------- Forwarded message ---------- > From: Alexander Mayrhofer > Date: 06-Sep-2006 16:12 > Subject: [Enum] thinking about an "location" Enumservice > To: "enum@ietf.org" > > > > Hi, > > i'm thinking about whether to start working on a "location" Enumservice > (which would allow to refer from a phone number to the location of the > associated device). I'm well aware of the work in GEOPRIV and ECRIT - > however, some users (like hotels, tourist information, businesses eg.) might > want to openly publish their location associated with a phone number, > because their location can already be derived from eg. an web page etc. > > Actually, there would be at least two "indirect" ways of doing that: > > - using a "E2U+pres" Enumservice, which refers to a pres: URI, which in turn > resolves to a PIDF document. That PIDF could be enhanced with PIDF-LO data. > > - using a "E2U+vcard:..." Enumservice, which points to a vCard instance with > a GEO property > > - using a "LOC" resource record (RFC1876) [this would not be "full" ENUM] > > I'd appreciate comments whether we should a) explicitely recommend one of > those solutions above, or b) draft a new "location" (or "geo") Enumservice? > > cheers > > Alex > > _______________________________________________ > 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 Wed Sep 06 14:04:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL1l0-0007N0-C9; Wed, 06 Sep 2006 14:04:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL1ky-0007Mi-V8 for enum@ietf.org; Wed, 06 Sep 2006 14:04:12 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL1kx-0008Jh-MD for enum@ietf.org; Wed, 06 Sep 2006 14:04:12 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GL1ko-0007zQ-0J; Wed, 06 Sep 2006 13:04:02 -0500 From: "Brian Rosen" To: "'Alexander Mayrhofer'" , Subject: RE: [Enum] thinking about an "location" Enumservice Date: Wed, 6 Sep 2006 14:04:05 -0400 Message-ID: <02a301c6d1de$d93cc060$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44FEE55E.2020800@enum.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbRyYb9E5dd/y1pRGSlOy5SU6/HqQAFRL+w X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 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 I think vcard or pidf will serve all the uses I can think of. I think you should recommend pidf unless the other properties of vcard are useful. I think defining a new form is a bad idea. Brian > -----Original Message----- > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > Sent: Wednesday, September 06, 2006 11:13 AM > To: 'enum@ietf.org' > Subject: [Enum] thinking about an "location" Enumservice > > > Hi, > > i'm thinking about whether to start working on a "location" Enumservice > (which would allow to refer from a phone number to the location of the > associated device). I'm well aware of the work in GEOPRIV and ECRIT - > however, some users (like hotels, tourist information, businesses eg.) > might > want to openly publish their location associated with a phone number, > because their location can already be derived from eg. an web page etc. > > Actually, there would be at least two "indirect" ways of doing that: > > - using a "E2U+pres" Enumservice, which refers to a pres: URI, which in > turn > resolves to a PIDF document. That PIDF could be enhanced with PIDF-LO > data. > > - using a "E2U+vcard:..." Enumservice, which points to a vCard instance > with > a GEO property > > - using a "LOC" resource record (RFC1876) [this would not be "full" ENUM] > > I'd appreciate comments whether we should a) explicitely recommend one of > those solutions above, or b) draft a new "location" (or "geo") > Enumservice? > > cheers > > Alex > > _______________________________________________ > 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 Wed Sep 06 15:50:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3PY-0005wj-AM; Wed, 06 Sep 2006 15:50:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3PO-0005oe-Uf; Wed, 06 Sep 2006 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL3PO-0001Lb-M4; Wed, 06 Sep 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 8069626E3D; Wed, 6 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GL3PO-00028w-8p; Wed, 06 Sep 2006 15:50:02 -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: Wed, 06 Sep 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-vcard-04.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 : IANA Registration for vCard Enumservice Author(s) : A. Mayrhofer Filename : draft-ietf-enum-vcard-04.txt Pages : 10 Date : 2006-9-6 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 3761. 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-04.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-vcard-04.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-vcard-04.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-9-6121726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-vcard-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-vcard-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-6121726.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 Wed Sep 06 15:50:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3PP-0005qJ-KY; Wed, 06 Sep 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 1GL3PO-0005oE-Bh; Wed, 06 Sep 2006 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL3PO-0001LQ-4L; Wed, 06 Sep 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1A6C126E2F; Wed, 6 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GL3PN-00028H-W9; Wed, 06 Sep 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: Wed, 06 Sep 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-edns0-00.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 : ENUM Requirement for EDNS0 Support Author(s) : L. Conroy, J. Reid Filename : draft-ietf-enum-edns0-00.txt Pages : 16 Date : 2006-9-6 Support for EDNS0 (Extension Mechanisms for DNS) is mandated in this document for DNS entities querying for or serving NAPTR records. In general those entities will be supporting ENUM resolution. This requirement is needed because DNS responses to ENUM-related queries generally return large RRSets. Without EDNS0 support these lookups would result in truncated responses and repeated queries over TCP transport. That has a severe impact on DNS server load and on the latency of those queries. This document adds an operational requirement to use of the protocol standardised in RFC 3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-edns0-00.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-edns0-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-ietf-enum-edns0-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. --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-9-6113247.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-edns0-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-edns0-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-6113247.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 Wed Sep 06 16:12:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3l0-00036q-0z; Wed, 06 Sep 2006 16:12:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3kz-00035s-1I for enum@ietf.org; Wed, 06 Sep 2006 16:12:21 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GL3kx-0004Zm-Ip for enum@ietf.org; Wed, 06 Sep 2006 16:12:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] thinking about an "location" Enumservice Date: Wed, 6 Sep 2006 22:11:22 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B61@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] thinking about an "location" Enumservice Thread-Index: AcbRyYb9E5dd/y1pRGSlOy5SU6/HqQAFRL+wAAROBkY= References: <02a301c6d1de$d93cc060$640fa8c0@cis.neustar.com> From: "Stastny Richard" To: "Brian Rosen" , "Alexander Mayrhofer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: 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 Considering the intended usage of a location information (giving the location of hotels and other public places) I would prefer to have an enumservice "loc" dedicated for giving a location, so you can look and filter for it =20 This may pont to a vcard or pidf-lo, whatever =20 Richard ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Mi 06.09.2006 20:04 An: 'Alexander Mayrhofer'; enum@ietf.org Betreff: RE: [Enum] thinking about an "location" Enumservice I think vcard or pidf will serve all the uses I can think of. I think = you should recommend pidf unless the other properties of vcard are useful. = I think defining a new form is a bad idea. Brian > -----Original Message----- > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > Sent: Wednesday, September 06, 2006 11:13 AM > To: 'enum@ietf.org' > Subject: [Enum] thinking about an "location" Enumservice > > > Hi, > > i'm thinking about whether to start working on a "location" = Enumservice > (which would allow to refer from a phone number to the location of the > associated device). I'm well aware of the work in GEOPRIV and ECRIT - > however, some users (like hotels, tourist information, businesses eg.) > might > want to openly publish their location associated with a phone number, > because their location can already be derived from eg. an web page = etc. > > Actually, there would be at least two "indirect" ways of doing that: > > - using a "E2U+pres" Enumservice, which refers to a pres: URI, which = in > turn > resolves to a PIDF document. That PIDF could be enhanced with PIDF-LO > data. > > - using a "E2U+vcard:..." Enumservice, which points to a vCard = instance > with > a GEO property > > - using a "LOC" resource record (RFC1876) [this would not be "full" = ENUM] > > I'd appreciate comments whether we should a) explicitely recommend one = of > those solutions above, or b) draft a new "location" (or "geo") > Enumservice? > > cheers > > Alex > > _______________________________________________ > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 06 16:16:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3pP-0004NQ-Jn; Wed, 06 Sep 2006 16:16:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3pO-0004My-Dp for enum@ietf.org; Wed, 06 Sep 2006 16:16:54 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL3pN-0005OX-3O for enum@ietf.org; Wed, 06 Sep 2006 16:16:54 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GL3pD-0006aY-At; Wed, 06 Sep 2006 15:16:43 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'Alexander Mayrhofer'" , Subject: RE: [Enum] thinking about an "location" Enumservice Date: Wed, 6 Sep 2006 16:16:46 -0400 Message-ID: <036801c6d1f1$63265d60$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B61@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbRyYb9E5dd/y1pRGSlOy5SU6/HqQAFRL+wAAROBkYAAFFOwA== X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: 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 Seems to me like what you often want is a vcard, which contains a lot of info besides location. If all you need is location, a PIDF-LO can give you that without much overhead. Inventing a NEW format seems unwise. Brian > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, September 06, 2006 4:11 PM > To: Brian Rosen; Alexander Mayrhofer; enum@ietf.org > Subject: Re: [Enum] thinking about an "location" Enumservice > > Considering the intended usage of a location information > (giving the location of hotels and other public places) > I would prefer to have an enumservice "loc" dedicated > for giving a location, so you can look and filter for it > > This may pont to a vcard or pidf-lo, whatever > > Richard > > ________________________________ > > Von: Brian Rosen [mailto:br@brianrosen.net] > Gesendet: Mi 06.09.2006 20:04 > An: 'Alexander Mayrhofer'; enum@ietf.org > Betreff: RE: [Enum] thinking about an "location" Enumservice > > > > I think vcard or pidf will serve all the uses I can think of. I think you > should recommend pidf unless the other properties of vcard are useful. I > think defining a new form is a bad idea. > > Brian > > > -----Original Message----- > > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > > Sent: Wednesday, September 06, 2006 11:13 AM > > To: 'enum@ietf.org' > > Subject: [Enum] thinking about an "location" Enumservice > > > > > > Hi, > > > > i'm thinking about whether to start working on a "location" Enumservice > > (which would allow to refer from a phone number to the location of the > > associated device). I'm well aware of the work in GEOPRIV and ECRIT - > > however, some users (like hotels, tourist information, businesses eg.) > > might > > want to openly publish their location associated with a phone number, > > because their location can already be derived from eg. an web page etc. > > > > Actually, there would be at least two "indirect" ways of doing that: > > > > - using a "E2U+pres" Enumservice, which refers to a pres: URI, which in > > turn > > resolves to a PIDF document. That PIDF could be enhanced with PIDF-LO > > data. > > > > - using a "E2U+vcard:..." Enumservice, which points to a vCard instance > > with > > a GEO property > > > > - using a "LOC" resource record (RFC1876) [this would not be "full" > ENUM] > > > > I'd appreciate comments whether we should a) explicitely recommend one > of > > those solutions above, or b) draft a new "location" (or "geo") > > Enumservice? > > > > cheers > > > > Alex > > > > _______________________________________________ > > 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 > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 06 16:28:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL40M-0007Mg-Lw; Wed, 06 Sep 2006 16:28:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL40L-0007MV-7u for enum@ietf.org; Wed, 06 Sep 2006 16:28:13 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GL40J-0006lf-Nd for enum@ietf.org; Wed, 06 Sep 2006 16:28:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] thinking about an "location" Enumservice Date: Wed, 6 Sep 2006 22:27:21 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B62@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] thinking about an "location" Enumservice Thread-Index: AcbRyYb9E5dd/y1pRGSlOy5SU6/HqQAFRL+wAAROBkYAAFFOwAAAGX3V References: <036801c6d1f1$63265d60$640fa8c0@cis.neustar.com> From: "Stastny Richard" To: "Brian Rosen" , "Alexander Mayrhofer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: 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 Brian, =20 you did not seem to have read what I wrote =20 I did not say to invent a new format =20 I only wanted to make sure that if you look for a location you get a location, so I want an ENUMSERIVICE pointing definitely to a location e.g. =20 "E2U+loc:vcard" and/or "E2U+loc:pidf" =20 Enumservice vcard may point to a vcard not having a location =20 Richard =20 ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Mi 06.09.2006 22:16 An: Stastny Richard; 'Alexander Mayrhofer'; enum@ietf.org Betreff: RE: [Enum] thinking about an "location" Enumservice Seems to me like what you often want is a vcard, which contains a lot of info besides location. If all you need is location, a PIDF-LO can give = you that without much overhead. Inventing a NEW format seems unwise. Brian > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, September 06, 2006 4:11 PM > To: Brian Rosen; Alexander Mayrhofer; enum@ietf.org > Subject: Re: [Enum] thinking about an "location" Enumservice > > Considering the intended usage of a location information > (giving the location of hotels and other public places) > I would prefer to have an enumservice "loc" dedicated > for giving a location, so you can look and filter for it > > This may pont to a vcard or pidf-lo, whatever > > Richard > > ________________________________ > > Von: Brian Rosen [mailto:br@brianrosen.net] > Gesendet: Mi 06.09.2006 20:04 > An: 'Alexander Mayrhofer'; enum@ietf.org > Betreff: RE: [Enum] thinking about an "location" Enumservice > > > > I think vcard or pidf will serve all the uses I can think of. I think = you > should recommend pidf unless the other properties of vcard are useful. = I > think defining a new form is a bad idea. > > Brian > > > -----Original Message----- > > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > > Sent: Wednesday, September 06, 2006 11:13 AM > > To: 'enum@ietf.org' > > Subject: [Enum] thinking about an "location" Enumservice > > > > > > Hi, > > > > i'm thinking about whether to start working on a "location" = Enumservice > > (which would allow to refer from a phone number to the location of = the > > associated device). I'm well aware of the work in GEOPRIV and ECRIT = - > > however, some users (like hotels, tourist information, businesses = eg.) > > might > > want to openly publish their location associated with a phone = number, > > because their location can already be derived from eg. an web page = etc. > > > > Actually, there would be at least two "indirect" ways of doing that: > > > > - using a "E2U+pres" Enumservice, which refers to a pres: URI, which = in > > turn > > resolves to a PIDF document. That PIDF could be enhanced with = PIDF-LO > > data. > > > > - using a "E2U+vcard:..." Enumservice, which points to a vCard = instance > > with > > a GEO property > > > > - using a "LOC" resource record (RFC1876) [this would not be "full" > ENUM] > > > > I'd appreciate comments whether we should a) explicitely recommend = one > of > > those solutions above, or b) draft a new "location" (or "geo") > > Enumservice? > > > > cheers > > > > Alex > > > > _______________________________________________ > > 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 > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 06 16:54:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL4Pd-0006AO-53; Wed, 06 Sep 2006 16:54:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL4Pc-0006AJ-Hq for enum@ietf.org; Wed, 06 Sep 2006 16:54:20 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL4Pa-0001xg-V4 for enum@ietf.org; Wed, 06 Sep 2006 16:54:20 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GL4PR-0001HF-IS; Wed, 06 Sep 2006 15:54:10 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'Alexander Mayrhofer'" , Subject: RE: [Enum] thinking about an "location" Enumservice Date: Wed, 6 Sep 2006 16:54:14 -0400 Message-ID: <038701c6d1f6$9e3a03c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B62@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbRyYb9E5dd/y1pRGSlOy5SU6/HqQAFRL+wAAROBkYAAFFOwAAAGX3VAAEqeUA= X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: 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 Can you or Alex come up with a use case where the ONLY thing the enum client wants is location and getting other information besides location is not wanted? The server can always deliver a vcard or a pidf that only contained location if it insists on it, but an enumservice wouldn't be needed for that. I'm having a hard time understanding why the client would ask for location exclusive of anything else it might find in a vcard or a pidf. Brian > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, September 06, 2006 4:27 PM > To: Brian Rosen; Alexander Mayrhofer; enum@ietf.org > Subject: Re: [Enum] thinking about an "location" Enumservice > > Brian, > > you did not seem to have read what I wrote > > I did not say to invent a new format > > I only wanted to make sure that if you look for a location > you get a location, so I want an ENUMSERIVICE pointing > definitely to a location e.g. > > "E2U+loc:vcard" and/or > "E2U+loc:pidf" > > Enumservice vcard may point to a vcard not having a location > > Richard > > > ________________________________ > > Von: Brian Rosen [mailto:br@brianrosen.net] > Gesendet: Mi 06.09.2006 22:16 > An: Stastny Richard; 'Alexander Mayrhofer'; enum@ietf.org > Betreff: RE: [Enum] thinking about an "location" Enumservice > > > > Seems to me like what you often want is a vcard, which contains a lot of > info besides location. If all you need is location, a PIDF-LO can give > you > that without much overhead. Inventing a NEW format seems unwise. > > Brian > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, September 06, 2006 4:11 PM > > To: Brian Rosen; Alexander Mayrhofer; enum@ietf.org > > Subject: Re: [Enum] thinking about an "location" Enumservice > > > > Considering the intended usage of a location information > > (giving the location of hotels and other public places) > > I would prefer to have an enumservice "loc" dedicated > > for giving a location, so you can look and filter for it > > > > This may pont to a vcard or pidf-lo, whatever > > > > Richard > > > > ________________________________ > > > > Von: Brian Rosen [mailto:br@brianrosen.net] > > Gesendet: Mi 06.09.2006 20:04 > > An: 'Alexander Mayrhofer'; enum@ietf.org > > Betreff: RE: [Enum] thinking about an "location" Enumservice > > > > > > > > I think vcard or pidf will serve all the uses I can think of. I think > you > > should recommend pidf unless the other properties of vcard are useful. > I > > think defining a new form is a bad idea. > > > > Brian > > > > > -----Original Message----- > > > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > > > Sent: Wednesday, September 06, 2006 11:13 AM > > > To: 'enum@ietf.org' > > > Subject: [Enum] thinking about an "location" Enumservice > > > > > > > > > Hi, > > > > > > i'm thinking about whether to start working on a "location" > Enumservice > > > (which would allow to refer from a phone number to the location of the > > > associated device). I'm well aware of the work in GEOPRIV and ECRIT - > > > however, some users (like hotels, tourist information, businesses eg.) > > > might > > > want to openly publish their location associated with a phone number, > > > because their location can already be derived from eg. an web page > etc. > > > > > > Actually, there would be at least two "indirect" ways of doing that: > > > > > > - using a "E2U+pres" Enumservice, which refers to a pres: URI, which > in > > > turn > > > resolves to a PIDF document. That PIDF could be enhanced with PIDF-LO > > > data. > > > > > > - using a "E2U+vcard:..." Enumservice, which points to a vCard > instance > > > with > > > a GEO property > > > > > > - using a "LOC" resource record (RFC1876) [this would not be "full" > > ENUM] > > > > > > I'd appreciate comments whether we should a) explicitely recommend one > > of > > > those solutions above, or b) draft a new "location" (or "geo") > > > Enumservice? > > > > > > cheers > > > > > > Alex > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 06 17:01:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL4WV-0000VX-6W; Wed, 06 Sep 2006 17:01:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL4WT-0000VN-Kb for enum@ietf.org; Wed, 06 Sep 2006 17:01:25 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GL4WS-0003Bd-0h for enum@ietf.org; Wed, 06 Sep 2006 17:01:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] thinking about an "location" Enumservice Date: Wed, 6 Sep 2006 22:56:29 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B63@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] thinking about an "location" Enumservice Thread-Index: AcbRyYb9E5dd/y1pRGSlOy5SU6/HqQAFRL+wAAROBkYAAFFOwAAAGX3VAAEqeUAAADGFVA== References: <038701c6d1f6$9e3a03c0$640fa8c0@cis.neustar.com> From: "Stastny Richard" To: "Brian Rosen" , "Alexander Mayrhofer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: 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 E.g: You rent a car with a navigation device at the airport (connected via WiFi or GPRS to the Internet) and just have to enter the phone number of the hotel to get the GPS coordinates =20 Richard ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Mi 06.09.2006 22:54 An: Stastny Richard; 'Alexander Mayrhofer'; enum@ietf.org Betreff: RE: [Enum] thinking about an "location" Enumservice Can you or Alex come up with a use case where the ONLY thing the enum = client wants is location and getting other information besides location is not wanted? The server can always deliver a vcard or a pidf that only = contained location if it insists on it, but an enumservice wouldn't be needed for that. I'm having a hard time understanding why the client would ask for location exclusive of anything else it might find in a vcard or a pidf. Brian > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, September 06, 2006 4:27 PM > To: Brian Rosen; Alexander Mayrhofer; enum@ietf.org > Subject: Re: [Enum] thinking about an "location" Enumservice > > Brian, > > you did not seem to have read what I wrote > > I did not say to invent a new format > > I only wanted to make sure that if you look for a location > you get a location, so I want an ENUMSERIVICE pointing > definitely to a location e.g. > > "E2U+loc:vcard" and/or > "E2U+loc:pidf" > > Enumservice vcard may point to a vcard not having a location > > Richard > > > ________________________________ > > Von: Brian Rosen [mailto:br@brianrosen.net] > Gesendet: Mi 06.09.2006 22:16 > An: Stastny Richard; 'Alexander Mayrhofer'; enum@ietf.org > Betreff: RE: [Enum] thinking about an "location" Enumservice > > > > Seems to me like what you often want is a vcard, which contains a lot = of > info besides location. If all you need is location, a PIDF-LO can = give > you > that without much overhead. Inventing a NEW format seems unwise. > > Brian > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, September 06, 2006 4:11 PM > > To: Brian Rosen; Alexander Mayrhofer; enum@ietf.org > > Subject: Re: [Enum] thinking about an "location" Enumservice > > > > Considering the intended usage of a location information > > (giving the location of hotels and other public places) > > I would prefer to have an enumservice "loc" dedicated > > for giving a location, so you can look and filter for it > > > > This may pont to a vcard or pidf-lo, whatever > > > > Richard > > > > ________________________________ > > > > Von: Brian Rosen [mailto:br@brianrosen.net] > > Gesendet: Mi 06.09.2006 20:04 > > An: 'Alexander Mayrhofer'; enum@ietf.org > > Betreff: RE: [Enum] thinking about an "location" Enumservice > > > > > > > > I think vcard or pidf will serve all the uses I can think of. I = think > you > > should recommend pidf unless the other properties of vcard are = useful. > I > > think defining a new form is a bad idea. > > > > Brian > > > > > -----Original Message----- > > > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > > > Sent: Wednesday, September 06, 2006 11:13 AM > > > To: 'enum@ietf.org' > > > Subject: [Enum] thinking about an "location" Enumservice > > > > > > > > > Hi, > > > > > > i'm thinking about whether to start working on a "location" > Enumservice > > > (which would allow to refer from a phone number to the location of = the > > > associated device). I'm well aware of the work in GEOPRIV and = ECRIT - > > > however, some users (like hotels, tourist information, businesses = eg.) > > > might > > > want to openly publish their location associated with a phone = number, > > > because their location can already be derived from eg. an web page > etc. > > > > > > Actually, there would be at least two "indirect" ways of doing = that: > > > > > > - using a "E2U+pres" Enumservice, which refers to a pres: URI, = which > in > > > turn > > > resolves to a PIDF document. That PIDF could be enhanced with = PIDF-LO > > > data. > > > > > > - using a "E2U+vcard:..." Enumservice, which points to a vCard > instance > > > with > > > a GEO property > > > > > > - using a "LOC" resource record (RFC1876) [this would not be = "full" > > ENUM] > > > > > > I'd appreciate comments whether we should a) explicitely recommend = one > > of > > > those solutions above, or b) draft a new "location" (or "geo") > > > Enumservice? > > > > > > cheers > > > > > > Alex > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 06 18:37:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL61H-00022K-QG; Wed, 06 Sep 2006 18:37:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL61H-00021V-2M for enum@ietf.org; Wed, 06 Sep 2006 18:37:19 -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 1GL61G-00022A-Te for enum@ietf.org; Wed, 06 Sep 2006 18:37:19 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GL5SD-0002yR-QT for enum@ietf.org; Wed, 06 Sep 2006 18:01:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] thinking about an "location" Enumservice Date: Wed, 6 Sep 2006 23:57:12 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B64@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] thinking about an "location" Enumservice Thread-Index: AcbRyYb9E5dd/y1pRGSlOy5SU6/HqQAFRL+wAAROBkYAAFFOwAAAGX3VAAEqeUAAADGFVAABTFogAADSdLM= References: <000001c6d1fc$6c414b20$640fa8c0@cis.neustar.com> From: "Stastny Richard" To: "Brian Rosen" , "Alexander Mayrhofer" , X-Spam-Score: -2.6 (--) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: 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 >Sure, but wouldn't a full vcard be an excellent response for anything = like >this? =20 yes =20 >You might want the address too, for example. The fact that you also >got the name of the manager wouldn't bother you a bit. =20 yes, that is why I may use a vcard, but I look for a locations >I just don't see a reason to invent a new enumservice to just get = location >from a phone number. =20 Does it hurt? What is the problem of having another enumservice? =20 Richard >Brian ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Mi 06.09.2006 23:35 An: Stastny Richard; 'Alexander Mayrhofer'; enum@ietf.org Betreff: RE: [Enum] thinking about an "location" Enumservice Sure, but wouldn't a full vcard be an excellent response for anything = like this? You might want the address too, for example. The fact that you = also got the name of the manager wouldn't bother you a bit. I just don't see a reason to invent a new enumservice to just get = location from a phone number. Brian > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, September 06, 2006 4:56 PM > To: Brian Rosen; Alexander Mayrhofer; enum@ietf.org > Subject: Re: [Enum] thinking about an "location" Enumservice > > E.g: > You rent a car with a navigation device at the airport > (connected via WiFi or GPRS to the Internet) > and just have to enter the phone number of the hotel > to get the GPS coordinates > > Richard > > ________________________________ > > Von: Brian Rosen [mailto:br@brianrosen.net] > Gesendet: Mi 06.09.2006 22:54 > An: Stastny Richard; 'Alexander Mayrhofer'; enum@ietf.org > Betreff: RE: [Enum] thinking about an "location" Enumservice > > > > Can you or Alex come up with a use case where the ONLY thing the enum > client > wants is location and getting other information besides location is = not > wanted? The server can always deliver a vcard or a pidf that only > contained > location if it insists on it, but an enumservice wouldn't be needed = for > that. I'm having a hard time understanding why the client would ask = for > location exclusive of anything else it might find in a vcard or a = pidf. > > Brian > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, September 06, 2006 4:27 PM > > To: Brian Rosen; Alexander Mayrhofer; enum@ietf.org > > Subject: Re: [Enum] thinking about an "location" Enumservice > > > > Brian, > > > > you did not seem to have read what I wrote > > > > I did not say to invent a new format > > > > I only wanted to make sure that if you look for a location > > you get a location, so I want an ENUMSERIVICE pointing > > definitely to a location e.g. > > > > "E2U+loc:vcard" and/or > > "E2U+loc:pidf" > > > > Enumservice vcard may point to a vcard not having a location > > > > Richard > > > > > > ________________________________ > > > > Von: Brian Rosen [mailto:br@brianrosen.net] > > Gesendet: Mi 06.09.2006 22:16 > > An: Stastny Richard; 'Alexander Mayrhofer'; enum@ietf.org > > Betreff: RE: [Enum] thinking about an "location" Enumservice > > > > > > > > Seems to me like what you often want is a vcard, which contains a = lot of > > info besides location. If all you need is location, a PIDF-LO can = give > > you > > that without much overhead. Inventing a NEW format seems unwise. > > > > Brian > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, September 06, 2006 4:11 PM > > > To: Brian Rosen; Alexander Mayrhofer; enum@ietf.org > > > Subject: Re: [Enum] thinking about an "location" Enumservice > > > > > > Considering the intended usage of a location information > > > (giving the location of hotels and other public places) > > > I would prefer to have an enumservice "loc" dedicated > > > for giving a location, so you can look and filter for it > > > > > > This may pont to a vcard or pidf-lo, whatever > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Brian Rosen [mailto:br@brianrosen.net] > > > Gesendet: Mi 06.09.2006 20:04 > > > An: 'Alexander Mayrhofer'; enum@ietf.org > > > Betreff: RE: [Enum] thinking about an "location" Enumservice > > > > > > > > > > > > I think vcard or pidf will serve all the uses I can think of. I = think > > you > > > should recommend pidf unless the other properties of vcard are = useful. > > I > > > think defining a new form is a bad idea. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > > > > Sent: Wednesday, September 06, 2006 11:13 AM > > > > To: 'enum@ietf.org' > > > > Subject: [Enum] thinking about an "location" Enumservice > > > > > > > > > > > > Hi, > > > > > > > > i'm thinking about whether to start working on a "location" > > Enumservice > > > > (which would allow to refer from a phone number to the location = of > the > > > > associated device). I'm well aware of the work in GEOPRIV and = ECRIT > - > > > > however, some users (like hotels, tourist information, = businesses > eg.) > > > > might > > > > want to openly publish their location associated with a phone > number, > > > > because their location can already be derived from eg. an web = page > > etc. > > > > > > > > Actually, there would be at least two "indirect" ways of doing = that: > > > > > > > > - using a "E2U+pres" Enumservice, which refers to a pres: URI, = which > > in > > > > turn > > > > resolves to a PIDF document. That PIDF could be enhanced with = PIDF- > LO > > > > data. > > > > > > > > - using a "E2U+vcard:..." Enumservice, which points to a vCard > > instance > > > > with > > > > a GEO property > > > > > > > > - using a "LOC" resource record (RFC1876) [this would not be = "full" > > > ENUM] > > > > > > > > I'd appreciate comments whether we should a) explicitely = recommend > one > > > of > > > > those solutions above, or b) draft a new "location" (or "geo") > > > > Enumservice? > > > > > > > > cheers > > > > > > > > Alex > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 06 18:52:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL6Fz-0008W3-OU; Wed, 06 Sep 2006 18:52:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL6Ft-0008Sn-Ax; Wed, 06 Sep 2006 18:52:25 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL6Da-0003oQ-6o; Wed, 06 Sep 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 2BFA132854; Wed, 6 Sep 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GL6Da-0003UL-28; Wed, 06 Sep 2006 18:50:02 -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: Wed, 06 Sep 2006 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-arch-04.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 : ENUM Validation Architecture Author(s) : A. Mayrhofer, B. Hoeneisen Filename : draft-ietf-enum-validation-arch-04.txt Pages : 18 Date : 2006-9-6 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not 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 validation requirements and a high level architecture for an ENUM validation infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-04.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-validation-arch-04.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-validation-arch-04.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-9-6151253.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-validation-arch-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-validation-arch-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-6151253.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 Wed Sep 06 19:40:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL6z0-0006gh-9L; Wed, 06 Sep 2006 19:39:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL6yz-0006gY-4m for enum@ietf.org; Wed, 06 Sep 2006 19:39:01 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL6yw-0005mA-U1 for enum@ietf.org; Wed, 06 Sep 2006 19:39:01 -0400 Received: from dynamic-acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GL6ym-0005eo-Gb; Wed, 06 Sep 2006 18:38:48 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'Alexander Mayrhofer'" , Subject: RE: [Enum] thinking about an "location" Enumservice Date: Wed, 6 Sep 2006 19:38:54 -0400 Message-ID: <005601c6d20d$9f204da0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbRyYb9E5dd/y1pRGSlOy5SU6/HqQAFRL+wAAROBkYAAFFOwAAAGX3VAAEqeUAAADGFVAABTFogAADSdLMAA4BLIA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B64@oefeg-s04.oefeg.loc> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: 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 > Does it hurt? What is the problem of having another enumservice? Interoperability: client implements loc+pidf, server only implements pidf. They COULD have interworked, but they can't. You can't require all servers to implement all enumservices for all numbers. Having too many services that overlap is a very bad idea I think. Brian _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 06 22:58:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLA4z-0006k8-MR; Wed, 06 Sep 2006 22:57:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLA4y-0006jS-5Y for enum@ietf.org; Wed, 06 Sep 2006 22:57:24 -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 1GL61w-00022A-33 for enum@ietf.org; Wed, 06 Sep 2006 18:38:00 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GL54b-0002LQ-Va for enum@ietf.org; Wed, 06 Sep 2006 17:36:49 -0400 Received: from dynamic-acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GL53c-0004yX-BU; Wed, 06 Sep 2006 16:35:43 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'Alexander Mayrhofer'" , Subject: RE: [Enum] thinking about an "location" Enumservice Date: Wed, 6 Sep 2006 17:35:39 -0400 Message-ID: <000001c6d1fc$6c414b20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbRyYb9E5dd/y1pRGSlOy5SU6/HqQAFRL+wAAROBkYAAFFOwAAAGX3VAAEqeUAAADGFVAABTFog X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B63@oefeg-s04.oefeg.loc> X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.6 (--) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: 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 Sure, but wouldn't a full vcard be an excellent response for anything like this? You might want the address too, for example. The fact that you also got the name of the manager wouldn't bother you a bit. I just don't see a reason to invent a new enumservice to just get location from a phone number. Brian > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, September 06, 2006 4:56 PM > To: Brian Rosen; Alexander Mayrhofer; enum@ietf.org > Subject: Re: [Enum] thinking about an "location" Enumservice > > E.g: > You rent a car with a navigation device at the airport > (connected via WiFi or GPRS to the Internet) > and just have to enter the phone number of the hotel > to get the GPS coordinates > > Richard > > ________________________________ > > Von: Brian Rosen [mailto:br@brianrosen.net] > Gesendet: Mi 06.09.2006 22:54 > An: Stastny Richard; 'Alexander Mayrhofer'; enum@ietf.org > Betreff: RE: [Enum] thinking about an "location" Enumservice > > > > Can you or Alex come up with a use case where the ONLY thing the enum > client > wants is location and getting other information besides location is not > wanted? The server can always deliver a vcard or a pidf that only > contained > location if it insists on it, but an enumservice wouldn't be needed for > that. I'm having a hard time understanding why the client would ask for > location exclusive of anything else it might find in a vcard or a pidf. > > Brian > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, September 06, 2006 4:27 PM > > To: Brian Rosen; Alexander Mayrhofer; enum@ietf.org > > Subject: Re: [Enum] thinking about an "location" Enumservice > > > > Brian, > > > > you did not seem to have read what I wrote > > > > I did not say to invent a new format > > > > I only wanted to make sure that if you look for a location > > you get a location, so I want an ENUMSERIVICE pointing > > definitely to a location e.g. > > > > "E2U+loc:vcard" and/or > > "E2U+loc:pidf" > > > > Enumservice vcard may point to a vcard not having a location > > > > Richard > > > > > > ________________________________ > > > > Von: Brian Rosen [mailto:br@brianrosen.net] > > Gesendet: Mi 06.09.2006 22:16 > > An: Stastny Richard; 'Alexander Mayrhofer'; enum@ietf.org > > Betreff: RE: [Enum] thinking about an "location" Enumservice > > > > > > > > Seems to me like what you often want is a vcard, which contains a lot of > > info besides location. If all you need is location, a PIDF-LO can give > > you > > that without much overhead. Inventing a NEW format seems unwise. > > > > Brian > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, September 06, 2006 4:11 PM > > > To: Brian Rosen; Alexander Mayrhofer; enum@ietf.org > > > Subject: Re: [Enum] thinking about an "location" Enumservice > > > > > > Considering the intended usage of a location information > > > (giving the location of hotels and other public places) > > > I would prefer to have an enumservice "loc" dedicated > > > for giving a location, so you can look and filter for it > > > > > > This may pont to a vcard or pidf-lo, whatever > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Brian Rosen [mailto:br@brianrosen.net] > > > Gesendet: Mi 06.09.2006 20:04 > > > An: 'Alexander Mayrhofer'; enum@ietf.org > > > Betreff: RE: [Enum] thinking about an "location" Enumservice > > > > > > > > > > > > I think vcard or pidf will serve all the uses I can think of. I think > > you > > > should recommend pidf unless the other properties of vcard are useful. > > I > > > think defining a new form is a bad idea. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > > > > Sent: Wednesday, September 06, 2006 11:13 AM > > > > To: 'enum@ietf.org' > > > > Subject: [Enum] thinking about an "location" Enumservice > > > > > > > > > > > > Hi, > > > > > > > > i'm thinking about whether to start working on a "location" > > Enumservice > > > > (which would allow to refer from a phone number to the location of > the > > > > associated device). I'm well aware of the work in GEOPRIV and ECRIT > - > > > > however, some users (like hotels, tourist information, businesses > eg.) > > > > might > > > > want to openly publish their location associated with a phone > number, > > > > because their location can already be derived from eg. an web page > > etc. > > > > > > > > Actually, there would be at least two "indirect" ways of doing that: > > > > > > > > - using a "E2U+pres" Enumservice, which refers to a pres: URI, which > > in > > > > turn > > > > resolves to a PIDF document. That PIDF could be enhanced with PIDF- > LO > > > > data. > > > > > > > > - using a "E2U+vcard:..." Enumservice, which points to a vCard > > instance > > > > with > > > > a GEO property > > > > > > > > - using a "LOC" resource record (RFC1876) [this would not be "full" > > > ENUM] > > > > > > > > I'd appreciate comments whether we should a) explicitely recommend > one > > > of > > > > those solutions above, or b) draft a new "location" (or "geo") > > > > Enumservice? > > > > > > > > cheers > > > > > > > > Alex > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 07 01:54:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLCpj-0005LU-UG; Thu, 07 Sep 2006 01:53:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLCpi-0005L2-Nq for enum@ietf.org; Thu, 07 Sep 2006 01:53:50 -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 1GLCpc-0001mm-DJ for enum@ietf.org; Thu, 07 Sep 2006 01:53:50 -0400 Received: from [192.168.1.206] (85-124-80-192.dynamic.xdsl-line.inode.at [::ffff:85.124.80.192]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 07 Sep 2006 07:53:40 +0200 id 0007C0BA.44FFB3E4.00005B73 Message-ID: <44FFB390.8080709@enum.at> Date: Thu, 07 Sep 2006 07:52:16 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: enum@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Enum] Re: I-D ACTION:draft-ietf-enum-vcard-04.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 Internet-Drafts@ietf.org wrote: > Title : IANA Registration for vCard Enumservice > Author(s) : A. Mayrhofer > Filename : draft-ietf-enum-vcard-04.txt > Pages : 10 > Date : 2006-9-6 > > 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 3761. 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. btw, i've done a prototype implementation of this Enumservice for Asterisk, available at: http://www.enum.at/index.php?id=522 Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 07 03:13:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLE3e-0007BE-9D; Thu, 07 Sep 2006 03:12:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLE3c-0007B8-L5 for enum@ietf.org; Thu, 07 Sep 2006 03:12:16 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLE3b-0008CM-9w for enum@ietf.org; Thu, 07 Sep 2006 03:12:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] thinking about an "location" Enumservice Date: Thu, 7 Sep 2006 09:11:15 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C5114@oefeg-s04.oefeg.loc> In-Reply-To: <005601c6d20d$9f204da0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] thinking about an "location" Enumservice Thread-Index: AcbRyYb9E5dd/y1pRGSlOy5SU6/HqQAFRL+wAAROBkYAAFFOwAAAGX3VAAEqeUAAADGFVAABTFogAADSdLMAA4BLIAAPrrww From: "Stastny Richard" To: "Brian Rosen" , "Alexander Mayrhofer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 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 > Interoperability: client implements loc+pidf, server only implements pidf. > They COULD have interworked, but they can't. > You can't require all servers to implement all enumservices for all > numbers. ? I do not get this In ENUM there are only clients - the "server" is the DNS A client needs only to implement the enumservices he is looking for. Richard > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, September 07, 2006 1:39 AM > To: Stastny Richard; 'Alexander Mayrhofer'; enum@ietf.org > Subject: RE: [Enum] thinking about an "location" Enumservice >=20 > > Does it hurt? What is the problem of having another enumservice? > Interoperability: client implements loc+pidf, server only implements pidf. > They COULD have interworked, but they can't. >=20 > You can't require all servers to implement all enumservices for all > numbers. > Having too many services that overlap is a very bad idea I think. >=20 > Brian _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 07 03:36:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLEQV-000894-F9; Thu, 07 Sep 2006 03:35:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLEQU-00088y-DL for enum@ietf.org; Thu, 07 Sep 2006 03:35:54 -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 1GLEQT-0003be-3P for enum@ietf.org; Thu, 07 Sep 2006 03:35:54 -0400 Received: from [10.10.0.64] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 07 Sep 2006 09:35:49 +0200 id 0007C052.44FFCBD5.000069A8 Message-ID: <44FFCB7F.4090006@enum.at> Date: Thu, 07 Sep 2006 09:34:23 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] thinking about an "location" Enumservice References: <32755D354E6B65498C3BD9FD496C7D463C5114@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C5114@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Stastny Richard wrote: >> Interoperability: client implements loc+pidf, server only implements > pidf. >> They COULD have interworked, but they can't. >> You can't require all servers to implement all enumservices for all >> numbers. > > ? I do not get this > In ENUM there are only clients - the "server" is the DNS > > A client needs only to implement the enumservices he is looking for. I think i understand Brian's issue, and actually i have to agree: Say you have 5 options to do it on the "client" side, and the same 5 options when publishing the information. A typical client implements 2 of those services, and a typical ENUM domains contains 2 of those services as well. That means that the client understands 40% of the possible services, and the server publishes 40% as well. However (according to my understanding of statistics, at least), the chance that client and ENUM domain overlap are therefore 0.4 * 0.4 = 0.16 -> 16% (given that everything is uniformly distributed). That means that in only 16% of the cases the information could be used (think of the old video rental stores who had to carry every movie in VHS, Video2000 and Beta). Hence, adding another option is probably not only reducing the chance that the new service is successful, it also reduces the chance of the other services to be widely deployed. comments? alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 07 03:55:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLEil-0006IG-D9; Thu, 07 Sep 2006 03:54:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLEij-0006Hh-Tx for enum@ietf.org; Thu, 07 Sep 2006 03:54:45 -0400 Received: from mx2.bluetie.com ([206.65.164.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLEU4-0004FE-J2 for enum@ietf.org; Thu, 07 Sep 2006 03:39:37 -0400 Received: from emta2.app.nyc1.bluetie.com (emta2.app.nyc1.bluetie.com [10.102.1.162]) by mx2.bluetie.com (Postfix) with ESMTP id B0C3CE01BE; Thu, 7 Sep 2006 03:39:38 -0400 (EDT) Received: from [125.63.194.59] (r125-63-194-59.cpe.unwired.net.au [125.63.194.59]) by emta2.app.nyc1.bluetie.com (Postfix) with ESMTP id 9254874019; Thu, 7 Sep 2006 03:39:27 -0400 (EDT) Message-ID: <44FFCC99.9060502@acm.org> Date: Thu, 07 Sep 2006 17:39:05 +1000 From: Kewin Stoeckigt User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Enum] thinking about an "location" Enumservice References: <000001c6d1fc$6c414b20$640fa8c0@cis.neustar.com> In-Reply-To: <000001c6d1fc$6c414b20$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: enum@ietf.org, 'Stastny Richard' , 'Alexander Mayrhofer' 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 Brian Rosen wrote: > Sure, but wouldn't a full vcard be an excellent response for anything like > this? You might want the address too, for example. The fact that you also > got the name of the manager wouldn't bother you a bit. > > I just don't see a reason to invent a new enumservice to just get location > from a phone number. But if you only have limited bandwidth (or not always "on" devices), it may makes sense to transmit only the required information, eg. the address. Why would I then care about the Hotel Managers name, etc.? > > Brian > --- SNIP --- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 07 07:50:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLINX-0001zF-Pu; Thu, 07 Sep 2006 07:49:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLINW-0001zA-Hv for enum@ietf.org; Thu, 07 Sep 2006 07:49:06 -0400 Received: from norman.insensate.co.uk ([213.152.49.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLINV-0006H2-5f for enum@ietf.org; Thu, 07 Sep 2006 07:49:06 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 440AD96F38; Thu, 7 Sep 2006 12:46:58 +0100 (BST) In-Reply-To: <005601c6d20d$9f204da0$640fa8c0@cis.neustar.com> References: <005601c6d20d$9f204da0$640fa8c0@cis.neustar.com> 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 Subject: Re: [Enum] thinking about an "location" Enumservice Date: Thu, 7 Sep 2006 12:49:01 +0100 To: enum@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 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 Brian, folks, I'm confused. Server? Client? loc+pidf? I thought this was ENUM. AFAICT - An ENUM client that handles an enumservice needs to know only that the NAPTR with an (I guess) enumservice of loc:pidf holds a URI indicates how it can get it pidf-loc data. The loc service type tells it that this points at location information and the sub-type pidf tells it the way it gets to that data. Conversely, loc:ldap might tell its that the NAPTR pointed at the same kind of info but that the way to get at it was via ldap: This has been the case since before RFC 3761 was coined. Either there's a server that can provide that data at the end of the URI, or there isn't. That server need know NOTHING of ENUM, or how the client of that protocol found out how to get there. What's wrong with that picture? all the best, Lawrence On 7 Sep 2006, at 00:38, Brian Rosen wrote: >> Does it hurt? What is the problem of having another enumservice? > Interoperability: client implements loc+pidf, server only > implements pidf. > They COULD have interworked, but they can't. > > You can't require all servers to implement all enumservices for all > numbers. > Having too many services that overlap is a very bad idea I think. > > Brian _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 11 04:40:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMhJd-0001bf-CB; Mon, 11 Sep 2006 04:38:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMhJc-0001bY-2T for enum@ietf.org; Mon, 11 Sep 2006 04:38:52 -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 1GMhJa-0000Nm-PG for enum@ietf.org; Mon, 11 Sep 2006 04:38:52 -0400 Received: from [10.10.0.64] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Mon, 11 Sep 2006 10:38:37 +0200 id 00000019.4505208D.00007768 Message-ID: <45052034.2010409@enum.at> Date: Mon, 11 Sep 2006 10:37:08 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) 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] IRIs in ENUM 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, i'm thinking about issues regarding use of IRIs with ENUM, with the work on 3761bis in mind. I'd appreciate comments on what i've found so far: - RFC3761 refers from E.164 numbers to URI, hence the replacement part of the regexp field must contain a URI. - RFC3987, Section 3 specifies how to map IRIs to URIs - essentially, this produces a "urlencoded" UTF-8 representation of the IRI (%HH style notation). - RFC3761 states at the end of section 2.4 that "The character set used to encode the substitution expression is UTF-8", but doesn't say anything about percent-encoding. Issues regarding the regex operation itself: - The application unique string for ENUM contains only digits. Those should go through the IRI->URI encoding process unaffected. - Therefore, matches and backreference results should only contain digits as well. Since those digits should never occur "percent encoded", the regex implementation does not need to be aware of that encoding. - Same for the result after backreferences have been applied. No encoding neccessary, because only digits can be added. So, considering that 3761 came out before 3987, i think that 3761bis should explicitely mention IRIs, and state something like "IRIs cannot be directly used with ENUM, but MUST be converted to URIs according to Section 3 of RFC3987". That would imho assure that the result from ENUM would alway be plain ASCII, even when IRIs are used. comments? Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 11 08:59:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMlLV-0007ai-RI; Mon, 11 Sep 2006 08:57:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMlLT-0007WQ-MP for enum@ietf.org; Mon, 11 Sep 2006 08:57:03 -0400 Received: from norman.insensate.co.uk ([213.152.49.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMlLS-0005hj-By for enum@ietf.org; Mon, 11 Sep 2006 08:57:03 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id C320D978F0; Mon, 11 Sep 2006 13:54:34 +0100 (BST) In-Reply-To: <45052034.2010409@enum.at> References: <45052034.2010409@enum.at> 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 Subject: Re: [Enum] IRIs in ENUM Date: Mon, 11 Sep 2006 13:56:47 +0100 To: Alexander Mayrhofer X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Hi folks, I can't resist it. See section 3 of the Experiences draft. all the best, Lawrence On 11 Sep 2006, at 09:37, Alexander Mayrhofer wrote: > Hi, > i'm thinking about issues regarding use of IRIs with ENUM, with the > work on > 3761bis in mind. I'd appreciate comments on what i've found so far: > That would imho assure that the result from ENUM would alway be > plain ASCII, > even when IRIs are used. Precisely true, but perhaps slightly misleading. e.g. an HTTP URI will have percent encoded characters if there are characters in it that are not in the URI scheme's unescaped character group. It's still encoded and the Web Server receiving a subsequent request would probably have to urldecode before use. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 11 09:21:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMlii-0001yy-2t; Mon, 11 Sep 2006 09:21:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMlih-0001xz-AG for enum@ietf.org; Mon, 11 Sep 2006 09:21:03 -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 1GMlig-0008As-1N for enum@ietf.org; Mon, 11 Sep 2006 09:21:03 -0400 Received: from [10.10.0.64] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Mon, 11 Sep 2006 15:20:58 +0200 id 0007C0CC.450562BA.00001DEB Message-ID: <45056260.6040903@enum.at> Date: Mon, 11 Sep 2006 15:19:28 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] IRIs in ENUM References: <45052034.2010409@enum.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 lconroy wrote: > Hi folks, > I can't resist it. See section 3 of the Experiences draft. Hi Lawrence, i actually expected that mail. However, we now have an RFC which specifies how to map IRIs to URIs, and IRI schemes are starting to pop up - so we have to do something about it. (not very productive, this message, i know ;) cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 11 13:54:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMpyd-00062a-Bl; Mon, 11 Sep 2006 13:53:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMpyc-00062V-AG for enum@ietf.org; Mon, 11 Sep 2006 13:53:46 -0400 Received: from norman.insensate.co.uk ([213.152.49.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMpya-0002ua-Vp for enum@ietf.org; Mon, 11 Sep 2006 13:53:46 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id EC89D979A0; Mon, 11 Sep 2006 18:51:28 +0100 (BST) In-Reply-To: <45056260.6040903@enum.at> References: <45052034.2010409@enum.at> <45056260.6040903@enum.at> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2048465F-6DA8-4190-8BA1-384CD55A7683@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] IRIs in ENUM Date: Mon, 11 Sep 2006 18:53:41 +0100 To: Alexander Mayrhofer X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Hi Alex, folks, OK - my mail did not include enough detail. (i) Section 3 (and particularly section 3.1) of the unloved Experiences draft has already covered this, including the explanation, justification and the proposed restrictions. (ii) I hope that everyone agrees that It Would Be Bad if rfc3761bis were to be incompatible with the existing clients (and provisioning systems) "out there". Thus it is pretty much necessary to mention IRIs, and then preclude them in their "naked" form. You also need to mention (and consider) IDNs, IMHO. Just Cut'n'paste section 3.1 of Experiences and you're probably done. [assuming that normative restrictions are OK in 3761bis :]. atb, L On 11 Sep 2006, at 14:19, Alexander Mayrhofer wrote: > lconroy wrote: >> Hi folks, >> I can't resist it. See section 3 of the Experiences draft. > > Hi Lawrence, > i actually expected that mail. However, we now have an RFC which > specifies > how to map IRIs to URIs, and IRI schemes are starting to pop up - > so we have > to do something about it. > > (not very productive, this message, i know ;) > > cheers > > Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 12 03:13:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN2R4-0001G8-Sr; Tue, 12 Sep 2006 03:11:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN2R4-0001Fg-41 for enum@ietf.org; Tue, 12 Sep 2006 03:11:58 -0400 Received: from wx-out-0506.google.com ([66.249.82.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN2R2-0001V9-U1 for enum@ietf.org; Tue, 12 Sep 2006 03:11:58 -0400 Received: by wx-out-0506.google.com with SMTP id t4so2202825wxc for ; Tue, 12 Sep 2006 00:11:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ZZBSS4Ccl9wnfrrsKCXAf/8R+P38BXZTDhvMkjAN2oPp7HNqHmq0P7DeOSGTh7BM+i2EfeoPbQ9i6wpNlFnSRV+WmTOU7kx8pNHnz18LEBk+3TwnN/z77Rq3gMN8M2JyIM+eDLA7j7t2jX6w5yF0hgFiGtytgSWkuYDfhtpCpdU= Received: by 10.90.105.20 with SMTP id d20mr1981474agc; Tue, 12 Sep 2006 00:11:56 -0700 (PDT) Received: by 10.90.67.18 with HTTP; Tue, 12 Sep 2006 00:11:56 -0700 (PDT) Message-ID: Date: Tue, 12 Sep 2006 08:11:56 +0100 From: "Lee Dryburgh" To: enum@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Enum] Does User ENUM provide end user value as it stands? 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 Folks. I've been struggling for much of this year to find a digital identity, which would service the real-time applications I have in mind, and is likely to be deployed. Lately my attention has been on ENUM as a candidate. I'm concerned that User ENUM will not see widespread adoption because AFAIS ENUM as it stands holds very questionable value for the end user. Which demographic of people do we see buying ENUM numbers and why? I strongly suspect that the market has changed since ENUM was devised - primarily the rise of Skype and others (including PSTN call in functionality) and the shine coming off SIP. I see huge potential value in E.164 (as a namespace/identity), particularly when stored in DNS. But what I do not see, is what User ENUM has to offer today that would generate adoption. In short, where is the value for the end subscriber? I appreciate the feedback from the ENUM community some weeks back on whether ENUM was anti-competitive and hope to receive feedback on this topic as well (end user value/adoption). Many Regards Lee _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 12 08:33:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN7RX-0007Zq-76; Tue, 12 Sep 2006 08:32:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN5wG-0000Sm-Tv for enum@ietf.org; Tue, 12 Sep 2006 06:56:25 -0400 Received: from cyclone.wcom.co.uk ([193.131.254.139] helo=cyclone.emea.verizonbusiness.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN5wG-0002Qn-9H for enum@ietf.org; Tue, 12 Sep 2006 06:56:24 -0400 Received: from cyclone.wcom.co.uk ([170.127.79.100] helo=cyclone.emea.mci.com) by cyclone.emea.verizonbusiness.com with esmtp (Exim 4.42) id 1GN5w4-0004W0-K6; Tue, 12 Sep 2006 10:56:14 +0000 Received: from borg.emea.verizonbusiness.com (borasco [170.127.64.31]) by cyclone.emea.mci.com (4.7.0.120) with ESMTP id ; Tue, 12 Sep 2006 11:56:03 +0100 (BST) Received: from ms-lon-exgw01.uk.mcilink.com ([170.127.78.40]) by borg.emea.verizonbusiness.com with esmtp (Exim 4.42) id 1GN5vv-0002ix-Gg; Tue, 12 Sep 2006 10:56:03 +0000 Received: by ms-lon-exgw01.uk.mcilink.com with Internet Mail Service (5.5.2657.72) id ; Tue, 12 Sep 2006 11:56:03 +0100 Message-ID: From: "Lupton, Ronan" To: "'Lee Dryburgh'" , enum@ietf.org Subject: RE: [Enum] Does User ENUM provide end user value as it stands? Date: Tue, 12 Sep 2006 11:56:02 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) MIME-Version: 1.0 (Generated by NET-TEL Mailguard SMTP version 4.0.1.40) X-VZ-EMEA-Spam-Score: -100.0 (---------------------------------------------------) X-VZ-EMEA-Signature: 573e4148fb3110dfd9fa75b9daa266c9 X-Spam-Score: 0.6 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 X-Mailman-Approved-At: Tue, 12 Sep 2006 08:32:45 -0400 Cc: 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="===============1345612462==" Errors-To: enum-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1345612462== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D65A.09659210" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C6D65A.09659210 Content-Type: text/plain Lee, This adoption and business modelling issue is something that most of the national and group ENUM 'think tanks' are toiling with on the User ENUM side of things. Standards in general in my view, provide the lowest common (value) denominator on which creative and innovative services can be based. Rhetorical question: What competitive differential is derived from an open standard? Short term super normal profit perhaps. You have referred to Skype in your last two mails. One thing that Skype has done successfully is provided a 'shrink wrapped' interface on proprietary code to access consumers. Consumers drive demand, that we know to be a fact, which you have correctly identified. If some innovative person or company could 'shrink wrap' ENUM or more relevantly NAPTRs and the .e164.arpa Tld and numbering/domain functionality in a similar fashion I contend that ENUM will 'just work'. There has been a push to have national administrations and regulatory adopt and trial ENUM CC.e164.arpa ranges. I replied directly to you on the anti-competitive comments re: ENUM as I don't really believe that your proposition holds too much truth. However I of course respect your opinion and thank you for providing food for thought on what has become a quiet ietf distro. ENUM has in my opinion some great User and Carrier uses in it's current state, portability being one of them and of course multiple address grooming for users. There are a few factors which negative migration en masse to ENUM, SIP services, Skype, Google voice etc. these are bottle necks in the supply chain for access services. In many territories the provision of robust access services is derisory, this is clearly a problem for innovators and policy makers. So in summary treat as lowest common (value) denominator, focus on NAPTR as the glue that binds the services and move on. Ronan Lupton Member of the 353 ENUM Policy Advisory Board **The views expressed in this message are the view of the author and do not represent any policy or company position** -----Original Message----- From: Lee Dryburgh [mailto:dryburghl@gmail.com] Sent: 12 September 2006 08:12 To: enum@ietf.org Subject: [Enum] Does User ENUM provide end user value as it stands? Hi Folks. I've been struggling for much of this year to find a digital identity, which would service the real-time applications I have in mind, and is likely to be deployed. Lately my attention has been on ENUM as a candidate. I'm concerned that User ENUM will not see widespread adoption because AFAIS ENUM as it stands holds very questionable value for the end user. Which demographic of people do we see buying ENUM numbers and why? I strongly suspect that the market has changed since ENUM was devised - primarily the rise of Skype and others (including PSTN call in functionality) and the shine coming off SIP. I see huge potential value in E.164 (as a namespace/identity), particularly when stored in DNS. But what I do not see, is what User ENUM has to offer today that would generate adoption. In short, where is the value for the end subscriber? I appreciate the feedback from the ENUM community some weeks back on whether ENUM was anti-competitive and hope to receive feedback on this topic as well (end user value/adoption). Many Regards Lee _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01C6D65A.09659210 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Enum] Does User ENUM provide end user value as it = stands?

Lee,

This adoption and business modelling issue is = something that most of the national and group ENUM 'think tanks' are = toiling with on the User ENUM side of things.

Standards in general in my view, provide the lowest = common (value) denominator on which creative and innovative services = can be based.

Rhetorical question: What competitive differential is = derived from an open standard? Short term super normal profit = perhaps.

You have referred to Skype in your last two mails. = One thing that Skype has done successfully is provided a 'shrink = wrapped' interface on proprietary code to access consumers. Consumers = drive demand, that we know to be a fact, which you have correctly = identified.

If some innovative person or company could 'shrink = wrap' ENUM or more relevantly NAPTRs and the .e164.arpa Tld and = numbering/domain functionality in a similar fashion I contend that ENUM = will 'just work'.

There has been a push to have national = administrations and regulatory adopt and trial ENUM CC.e164.arpa = ranges.

I replied directly to you on the anti-competitive = comments re: ENUM as I don't really believe that your proposition holds = too much truth. However I of course respect your opinion and thank you = for providing food for thought on what has become a quiet ietf = distro.

ENUM has in my opinion some great User and Carrier = uses in it's current state, portability being one of them and of course = multiple address grooming for users.

There are a few factors which negative migration en = masse to ENUM, SIP services, Skype, Google voice etc. these are bottle = necks in the supply chain for access services. In many territories the = provision of robust access services is derisory, this is clearly a = problem for innovators and policy makers.

So in summary treat as lowest common (value) = denominator, focus on NAPTR as the glue that binds the services and = move on.

Ronan Lupton

Member of the 353 ENUM Policy Advisory Board

**The views expressed in this message are the view of = the author and do not represent any policy or company position**

-----Original Message-----
From: Lee Dryburgh [mailto:dryburghl@gmail.com] =
Sent: 12 September 2006 08:12
To: enum@ietf.org
Subject: [Enum] Does User ENUM provide end user = value as it stands?

Hi Folks.

I've been struggling for much of this year to find a = digital identity, which would service the real-time applications I have = in mind, and is likely to be deployed. Lately my attention has been on = ENUM as a candidate.

I'm concerned that User ENUM will not see widespread = adoption because AFAIS ENUM as it stands holds very questionable value = for the end user. Which demographic of people do we see buying ENUM = numbers and why? I strongly suspect that the market has changed since = ENUM was devised - primarily the rise of Skype and others (including = PSTN call in functionality) and the shine coming off SIP.

I see huge potential value in E.164 (as a = namespace/identity), particularly when stored in DNS. But what I do not = see, is what User ENUM has to offer today that would generate adoption. = In short, where is the value for the end subscriber?

I appreciate the feedback from the ENUM community = some weeks back on whether ENUM was anti-competitive and hope to = receive feedback on this topic as well (end user = value/adoption).

Many Regards

Lee

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum=

------_=_NextPart_001_01C6D65A.09659210-- --===============1345612462== 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 --===============1345612462==-- From enum-bounces@ietf.org Tue Sep 12 08:47:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN7fW-0004El-CF; Tue, 12 Sep 2006 08:47:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN7fV-0004EV-IC for enum@ietf.org; Tue, 12 Sep 2006 08:47:13 -0400 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN7fT-0008HF-4A for enum@ietf.org; Tue, 12 Sep 2006 08:47:13 -0400 Received: from [195.54.233.66] (account jim HELO [195.54.233.66]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTPSA id 59760; Tue, 12 Sep 2006 13:47:10 +0100 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: <2665B518-2075-471C-9345-95116FCF26CD@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] Does User ENUM provide end user value as it stands? Date: Tue, 12 Sep 2006 13:47:08 +0100 To: Lee Dryburgh X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Sep 12, 2006, at 08:11, Lee Dryburgh wrote: > Which demographic of people do we see buying ENUM numbers and why? This is supposed to be a list for protocol engineers, not marketroids. :-) IMO, nobody will buy a user ENUM delegation in the same way as they buy a domain name in .com or whereever, even though the same roles and entities -- registrars, resellers, service providers and registries -- are involved. People will get an ENUM registration bundled with some higher-level service offering which is underpinned by ENUM. That could be VoIP. Or it could be IM. Or integrated messaging. Or some combination of these. Or.... If I'm right, the demographic for ENUM will ultimately be everyone that uses such services or "owns" a telephone number. The public won't even know an ENUM entry is there, just as they have no real understanding of the IMEI and SIMM serial numbers that underpin mobile telephony. > I strongly suspect that the market has changed since ENUM was > devised - primarily the rise of Skype and others (including PSTN call > in functionality) and the shine coming off SIP. Since there has been almost no user ENUM market to date, there is no market to change. :-) The uptake of Skype and other VoIP/IM services changes nothing IMO because they don't offer a generic solution to the rendezvous problem. If I'm on Google's VoIP service and you're on Skype's, how to I know how and where to find you and how do we establish some sort of communication between us? Or how can I find out you won't take a Skype or PSTN call but can be reached on say Yahoo's IM service? This is precisely where ENUM comes in. > I see huge potential value in E.164 (as a namespace/identity), > particularly when stored in DNS. But what I do not see, is what User > ENUM has to offer today that would generate adoption. In short, where > is the value for the end subscriber? Perhaps from all these sexy digital identity solutions you have up your sleeve? :-) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 18 16:53:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQ5y-0000mu-0w; Mon, 18 Sep 2006 16:52:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQ5w-0000mP-PI for enum@ietf.org; Mon, 18 Sep 2006 16:52:00 -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 1GPQ5p-0001Hc-Oz for enum@ietf.org; Mon, 18 Sep 2006 16:52:00 -0400 Received: from [192.168.1.104] (85-124-83-142.dynamic.xdsl-line.inode.at [::ffff:85.124.83.142]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Mon, 18 Sep 2006 22:51:39 +0200 id 00000030.450F06DB.000007B4 Message-ID: <450F067A.8030905@enum.at> Date: Mon, 18 Sep 2006 22:50:02 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: multipart/mixed; boundary="------------080704050209010402050008" X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [Enum] [Fwd: Protocol Action: 'The ENUM Dip Indicator parameter for the "tel" URI' to Proposed Standard] 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 is a multi-part message in MIME format. --------------080704050209010402050008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit fyi - progress. alex --------------080704050209010402050008 Content-Type: message/rfc822; name*0="Protocol Action: 'The ENUM Dip Indicator parameter for the \"te"; name*1="l\" URI' to Proposed Standard" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Protocol Action: 'The ENUM Dip Indicator parameter for the "; filename*1="\"tel\" URI' to Proposed Standard" Received: from megatron.ietf.org (optimus.ietf.org [::ffff:156.154.16.145]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Mon, 18 Sep 2006 22:48:06 +0200 id 00000030.450F0606.00000662 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPPzN-0002dm-Aa; Mon, 18 Sep 2006 16:45:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPPzL-0002cE-Mb for ietf-announce@ietf.org; Mon, 18 Sep 2006 16:45:11 -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 1GPPzL-0005Pb-KZ for ietf-announce@ietf.org; Mon, 18 Sep 2006 16:45:11 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GPPzJ-0005OM-Lk for ietf-announce@ietf.org; Mon, 18 Sep 2006 16:45:11 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 655CF1762C; Mon, 18 Sep 2006 20:44:39 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GPPyo-0000nD-Vm; Mon, 18 Sep 2006 16:44:38 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 18 Sep 2006 16:44:38 -0400 X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: iptel chair , Internet Architecture Board , RFC Editor Subject: Protocol Action: 'The ENUM Dip Indicator parameter for the "tel" URI' to Proposed Standard X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on pahula X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 The IESG has approved the following document: - 'The ENUM Dip Indicator parameter for the "tel" URI ' as a Proposed Standard This document is the product of the IP Telephony Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-enumdi-05.txt Technical Summary ENUM provides a way for a communication system to lookup a tel URI and see if alternative processing or routing can be applied to it. In some cases, such as when there is no entry in DNS for the ENUM lookup on that tel URI, each network element that processed the tel URI could end up repeating the lookup. This is inefficient. This specification defines an new "enumdi" parameter for the tel URI that indicates that an ENUM query has already been performed by a previous network element. This allows more efficient processing. Working Group Summary The working group reached consensus on this document. Protocol Quality This document received working group review over an extended period of time and was also reviewed by the ENUM WG. Alex Mayrhofer did a NITs review of the document. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --------------080704050209010402050008 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 --------------080704050209010402050008-- From enum-bounces@ietf.org Mon Sep 18 16:53:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQ67-0000pf-VT; Mon, 18 Sep 2006 16:52:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQ66-0000pI-MT for enum@ietf.org; Mon, 18 Sep 2006 16:52:10 -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 1GPQ65-0001Hc-7l for enum@ietf.org; Mon, 18 Sep 2006 16:52:10 -0400 Received: from [192.168.1.104] (85-124-83-142.dynamic.xdsl-line.inode.at [::ffff:85.124.83.142]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Mon, 18 Sep 2006 22:52:06 +0200 id 00000030.450F06F6.0000081A Message-ID: <450F0694.2060701@enum.at> Date: Mon, 18 Sep 2006 22:50:28 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: multipart/mixed; boundary="------------010306000608020602060204" X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [Enum] [Fwd: Document Action: 'ENUM Validation Architecture' to Informational RFC] 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 is a multi-part message in MIME format. --------------010306000608020602060204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit fyi. alex --------------010306000608020602060204 Content-Type: message/rfc822; name*0="Document Action: 'ENUM Validation Architecture' to Informationa"; name*1="l RFC" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Document Action: 'ENUM Validation Architecture' to Informat"; filename*1="ional RFC" Received: from megatron.ietf.org (odin.ietf.org [::ffff:156.154.16.145]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Mon, 18 Sep 2006 22:48:15 +0200 id 00000030.450F060F.00000683 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQ0E-0003jj-C6; Mon, 18 Sep 2006 16:46:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQ0C-0003fQ-9T for ietf-announce@ietf.org; Mon, 18 Sep 2006 16:46:04 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPQ0C-0005jy-3L for ietf-announce@ietf.org; Mon, 18 Sep 2006 16:46:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 10F32328E5; Mon, 18 Sep 2006 20:46:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GPQ0B-0000pH-V5; Mon, 18 Sep 2006 16:46:03 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 18 Sep 2006 16:46:03 -0400 X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: enum chair , Internet Architecture Board , RFC Editor Subject: Document Action: 'ENUM Validation Architecture' to Informational RFC X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on pahula X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 The IESG has approved the following document: - 'ENUM Validation Architecture ' as an Informational RFC This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-04.txt Technical Summary An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not 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 validation requirements and a high level architecture for an ENUM validation infrastructure. Working Group Summary This working group supports the direction of defining an ENUM validation process; this document is foundational to several others that are forthcoming. Protocol Quality This document was reviewed for the IESG by Jon Peterson. GEN-ART review was provided by David Black. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --------------010306000608020602060204 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 --------------010306000608020602060204-- From enum-bounces@ietf.org Sat Sep 23 06:32:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR4mU-0006mR-Rp; Sat, 23 Sep 2006 06:30:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR4mT-0006mM-DR for enum@ietf.org; Sat, 23 Sep 2006 06:30:45 -0400 Received: from s-utl01-lopop.stsn.net ([217.118.122.13]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GR4mS-0001gG-5h for enum@ietf.org; Sat, 23 Sep 2006 06:30:45 -0400 Received: from s-utl01-lopop.stsn.net ([127.0.0.1]) by s-utl01-lopop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2006092311303020547 for ; Sat, 23 Sep 2006 11:30:30 +0100 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: -0.334,BAYES_00: -1.665, BIZ_TLD: 2.434,SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from RSHOCKEYLTXP ([10.16.221.34]) by s-utl01-lopop.stsn.net for enum@ietf.org; Sat, 23 Sep 2006 11:30:28 +0100 From: "Richard Shockey" To: Date: Sat, 23 Sep 2006 06:30:07 -0400 Message-ID: <000501c6defb$452fdcc0$22dd100a@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.2962 Thread-Index: Acbe+zysU/md/nLMRmijdVg/cFT28w== X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Enum] Its that time again to start thinking about San Diego 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 Its agenda planning time again! If you plan on making a presentation for discussion you should get your drafts in ASAP and let the chairs know how much time you need etc. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz 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 Sat Sep 23 11:54:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR9oN-0002NJ-RD; Sat, 23 Sep 2006 11:53:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR9oM-0002MU-88 for enum@ietf.org; Sat, 23 Sep 2006 11:53:02 -0400 Received: from s-utl01-lopop.stsn.net ([217.118.122.13]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GR9ki-0002jn-Ny for enum@ietf.org; Sat, 23 Sep 2006 11:49:18 -0400 Received: from s-utl01-lopop.stsn.net ([127.0.0.1]) by s-utl01-lopop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2006092316485621163 for ; Sat, 23 Sep 2006 16:48:56 +0100 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.877,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from RSHOCKEYLTXP ([10.16.221.34]) by s-utl01-lopop.stsn.net for enum@ietf.org; Sat, 23 Sep 2006 16:48:54 +0100 From: "Richard Shockey" To: Date: Sat, 23 Sep 2006 11:48:38 -0400 Message-ID: <005a01c6df27$c37cc350$22dd100a@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.2962 Thread-Index: AcbbbI+rCWf6R7nJSUSAfnomzN3RWwDut4/A X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Enum] FW: Protocol Action: 'The ENUM Dip Indicator parameter for the "tel" URI' to Proposed Standard 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 FYI ... > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Monday, September 18, 2006 4:45 PM > To: IETF-Announce > Cc: iptel chair; Internet Architecture Board; RFC Editor > Subject: Protocol Action: 'The ENUM Dip Indicator parameter for the "tel" > URI' to Proposed Standard > > ----------------------------------------------------------- > The IESG has approved the following document: > > - 'The ENUM Dip Indicator parameter for the "tel" URI ' > as a Proposed Standard > > This document is the product of the IP Telephony Working Group. > > The IESG contact persons are Cullen Jennings and Jon Peterson. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-enumdi-05.txt > > Technical Summary > > ENUM provides a way for a communication system to lookup a tel URI and seeif alternative processing or routing can be applied to it. In some cases, such as when there is no entry in DNS for the ENUM lookup on that tel URI, each network element that processed the tel URI could end up repeating the lookup. This is inefficient. This specification defines an new> "enumdi" parameter for the tel URI that indicates that an ENUM query has already been performed by a previous network element. This allows more efficient processing. > Working Group Summary > > The working group reached consensus on this document. > > Protocol Quality > > This document received working group review over an extended period of > time and was also reviewed by the ENUM WG. Alex Mayrhofer did a NITs > review of the document. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 25 10:14:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrD3-0007hE-Cx; Mon, 25 Sep 2006 10:13:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrD2-0007h8-9O for enum@ietf.org; Mon, 25 Sep 2006 10:13:24 -0400 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound2-blu-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRrCx-0006Z6-0v for enum@ietf.org; Mon, 25 Sep 2006 10:13:24 -0400 Received: from outbound2-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-blu-R.bigfish.com (Postfix) with ESMTP id 510021A28DE3; Mon, 25 Sep 2006 14:12:58 +0000 (UTC) Received: from mail83-blu-R.bigfish.com (unknown [10.1.252.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by outbound2-blu.bigfish.com (Postfix) with ESMTP id 25B7E3013D; Mon, 25 Sep 2006 14:12:58 +0000 (UTC) Received: from mail83-blu (localhost.localdomain [127.0.0.1]) by mail83-blu-R.bigfish.com (Postfix) with ESMTP id AE83E5384FF; Mon, 25 Sep 2006 14:12:57 +0000 (UTC) X-BigFish: V Received: by mail83-blu (MessageSwitch) id 1159193577293013_9736; Mon, 25 Sep 2006 14:12:57 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail83-blu.bigfish.com (Postfix) with ESMTP id 037F615B007B; Mon, 25 Sep 2006 14:12:56 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k8PECubp026096; Mon, 25 Sep 2006 09:12:56 -0500 (CDT) Received: from plswg02a.ad.sprint.com (PLSWG02A.corp.sprint.com [10.214.11.48]) by mailhost.sprintspectrum.com (Switch-3.2.3/Switch-3.2.3) with ESMTP id k8PECdiv029447; Mon, 25 Sep 2006 09:12:40 -0500 (CDT) Received: from PDAWB15C.ad.sprint.com ([144.226.76.138]) by plswg02a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 09:12:38 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Its that time again to start thinking about San Diego Date: Mon, 25 Sep 2006 09:12:37 -0500 Message-ID: <92FFCF194CB9FF4CBA28EE5D5A89C15008B95CE5@PDAWB15C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Its that time again to start thinking about San Diego Thread-index: Acbe+zysU/md/nLMRmijdVg/cFT28wBsP2HA From: "Egbert, Brian G [CTO]" To: , X-OriginalArrivalTime: 25 Sep 2006 14:12:38.0519 (UTC) FILETIME=[A80F0070:01C6E0AC] X-Spam-Score: 0.6 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 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 =20 Hi Richard, I don't know about anyone else but I have an adjacent conference to the = meeting. Can/will you tell me what days of the week we will plan on = meeting? This will make a big impact on my travel plans. Thanks, Brian Brian G Egbert=20 Technology Development Specialist III=20 Global Technology Standards=20 6220 Sprint Parkway=20 Overland Park, KS 66215-6118=20 Office: (913) 794-4289=20 Wireless: (913) 226-6719=20 Brian.G.Egbert@sprint.com =20 -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: Saturday, September 23, 2006 5:30 AM To: enum@ietf.org Subject: [Enum] Its that time again to start thinking about San Diego Its agenda planning time again! If you plan on making a presentation for discussion you should get your = drafts in ASAP and let the chairs know how much time you need etc. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org = sip:5651(at)neustarlab.biz 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 Sep 25 10:52:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRroG-0002D0-Bt; Mon, 25 Sep 2006 10:51:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrnt-00024I-5J for enum@ietf.org; Mon, 25 Sep 2006 10:51:29 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRrky-0001sQ-3s for enum@ietf.org; Mon, 25 Sep 2006 10:48:31 -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 k8PEmFxc009633; Mon, 25 Sep 2006 07:48:23 -0700 From: "Richard Shockey" To: "'Egbert, Brian G [CTO]'" , Subject: RE: [Enum] Its that time again to start thinking about San Diego Date: Mon, 25 Sep 2006 10:47:53 -0400 Message-ID: <000001c6e0b1$97d575e0$6e201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acbe+zysU/md/nLMRmijdVg/cFT28wBsP2HAAAExxgA= In-Reply-To: <92FFCF194CB9FF4CBA28EE5D5A89C15008B95CE5@PDAWB15C.ad.sprint.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 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: 93e7fb8fef2e780414389440f367c879 Cc: 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 I understand the problem but right now I don't know. We will not see a preliminary meeting date for several weeks. Typically we are getting slots early in the week ( Mon Tue )but I wouldn't plan anything around that. 67th IETF Meeting Important Meeting Dates July 12, Week of - IETF Online Registration is now available August 7, Monday - Working Group and BOF scheduling begins. To request a Working Group session, use the IETF Meeting Session Request Tool September 18, Monday - Cutoff date for requests to schedule Working Group meetings and for preliminary BOF proposals to ADs at 17:00 ET (21:00 UTC/GMT). To request a Working Group session, use the IETF Meeting Session Request Tool September 25, Monday - Cutoff date for requests to schedule BOFs at 17:00 ET (21:00 UTC/GMT). September 29, Friday - Preliminary agenda published for comment. October 9, Monday - Working Group Chair approval for initial document (Version -00) submissions appreciated by 09:00 ET (13:00 UTC/GMT) October 11, Wednesday - Cutoff date for requests to reschedule Working Group and BOF meetings 09:00 ET (13:00 UTC/GMT) October 16, Monday - Final agenda to be published. October 16, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (13:00 UTC/GMT) October 23, Monday - Internet Draft final submission cut-off by 09:00 ET (13:00 UTC/GMT) October 25, Wednesday - Draft Working Group agendas due by 17:00 ET (21:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. October 27, Friday - Early-Bird registration and payment cut-off at 12:00 noon ET (16:00 UTC/GMT) October 30, Monday - Revised Working Group agendas due by 12:00 ET (17:00 UTC/GMT), upload using IETF Meeting Materials Management Tool October 30, Monday - Registration cancellation cut-off at 17:00 ET (22:00 UTC/GMT) November 4, Saturday - Final Pre-Registration and Pre-Payment cut-off at 17:00 ET (22:00 UTC/GMT) November 5-10, 2006 - 67th IETF Meeting in San Diego, CA December 8, Friday - Proceedings submission cutoff date by 17:00 ET (22:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. December 27, Wednesday - Proceedings submission corrections cutoff date by 17:00 ET (22:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. ** Times are in US Eastern Time and UTC/GMT ** > -----Original Message----- > From: Egbert, Brian G [CTO] [mailto:Brian.G.Egbert@sprint.com] > Sent: Monday, September 25, 2006 10:13 AM > To: richard@shockey.us; enum@ietf.org > Subject: RE: [Enum] Its that time again to start thinking about San Diego > > > Hi Richard, > > I don't know about anyone else but I have an adjacent conference to the > meeting. Can/will you tell me what days of the week we will plan on > meeting? This will make a big impact on my travel plans. > > Thanks, > > Brian > > Brian G Egbert > Technology Development Specialist III > Global Technology Standards > 6220 Sprint Parkway > Overland Park, KS 66215-6118 > Office: (913) 794-4289 > Wireless: (913) 226-6719 > Brian.G.Egbert@sprint.com > > > > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Saturday, September 23, 2006 5:30 AM > To: enum@ietf.org > Subject: [Enum] Its that time again to start thinking about San Diego > > > > Its agenda planning time again! > > If you plan on making a presentation for discussion you should get your > drafts in ASAP and let the chairs know how much time you need etc. > > > Richard Shockey > Director, Member of the Technical Staff > NeuStar > 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org > sip:5651(at)neustarlab.biz 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 29 13:35:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMEc-0002x5-28; Fri, 29 Sep 2006 13:33:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSsbz-0006OM-A5 for enum@ietf.org; Thu, 28 Sep 2006 05:55:23 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSsQS-0003Vo-HJ for enum@ietf.org; Thu, 28 Sep 2006 05:43:32 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 28 Sep 2006 02:43:28 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8S9hRPI015426; Thu, 28 Sep 2006 02:43: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 k8S9hRid024978; Thu, 28 Sep 2006 02:43: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 k8S9WesS013233; Thu, 28 Sep 2006 02:32:41 -0700 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: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 28 Sep 2006 11:43:02 +0200 To: IETF ENUM WG X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-5.cisco.com; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=20654; t=1159436607; x=1160300607; c=relaxed/simple; s=sjdkim5002; 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:draft-ietf-enum-uri-00.txt; X=v=3Dcisco.com=3B=20h=3Dgtn+ESeqelsZCSy7NfUKkiq7fXM=3D; b=tjJE/m2+PtFHMW2mvvKmcLZDsIavOi9RUYnCpvnKAL36Y390Six2NliFr7qGRyEAh/vKHivx MxlbiWi2EiStI3twRCp0vuGwRX/AE/WhN3fxUK66lGtNlgLA9lRm14QY; X-Spam-Score: 0.0 (/) X-Scan-Signature: 570a5b81f8c75fea8dcc4c9f6a8a6e54 Subject: [Enum] draft-ietf-enum-uri-00.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 This document was requested to be published the other day, but publication seems to take some time. This is the first document of two that together create RFC 3761bis. Patrik ENUM P. Faltstrom Internet-Draft Cisco Intended status: Standards Track O. Kolkman Expires: March 31, 2007 NLNet September 27, 2006 The Uniform Resource Identifier (URI) DNS Resource Record draft-ietf-enum-uri-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 March 31, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines a new DNS resource record, called the Uniform Resource Identifier (URI) RR, for publishing mappings from hostnames to URIs. Faltstrom & Kolkman Expires March 31, 2007 [Page 1] Internet-Draft URI Resource Record September 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 3. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 4 4. The format of the URI RR . . . . . . . . . . . . . . . . . . . 4 4.1. Ownername, class and type . . . . . . . . . . . . . . . . 4 4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.5. URI RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 4.6. The URI RR Presentation Format . . . . . . . . . . . . . . 6 5. Definition of the flag 'D' for NAPTR records . . . . . . . . . 6 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Homepage at one domain, but two domains in use . . . . . . 6 6.2. Different providers for services for the same E. 164 . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Non-normative references . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Faltstrom & Kolkman Expires March 31, 2007 [Page 2] Internet-Draft URI Resource Record September 2006 1. Introduction This document explains the use of the Domain Name System (DNS) for storage of URIs, and how to resolve hostnames to such URIs that can be used by various applications. For resolution the application need to know both the hostname and the protocol that the URI is to be used for. The protocol is registered by IANA. Currently, looking up URIs given a hostname uses the DDDS [RFC3401] application framework with the DNS as a database as specified in RFC 3404 [RFC3404]. This have a number of implications as described in draft-iab-dns-choices [I-D.iab-dns-choices] such as the inability to select what NAPTR records that match the query is interesting. The RRSet returned will always consist of all URIs "connected" with the domain in question. The URI resource record specified in this document create an ability for the querying party to select which ones of the NAPTR records one is interested in. This because data in the service field of the NAPTR record is included in the owner part of the URI resource record type. Querying for the URI resource record type is not replacing querying for the NAPTR (or S-NAPTR [RFC3958]) resource record type. Instead it is a complementary mechanism to use when one know already what service field is interesting. One can with the URI resource record type directly query for the specific subset of the otherwise possibly large RRSet given back when querying for NAPTR resource records. This document updates RFC 3958 and RFC 3404 by adding the flag "D" to the list of defined terminal flags in section 2.2.3 of RFC 3958 and 4.3 of RFC 3404. 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 BCP 14, RFC 2119 [RFC2119]. 2. Applicability Statement In general, it is expected that URI records will be used by clients for applications where the relevant protocol to be used is known, but for example extra abstraction given by separating a hostname from a point of service (as address by the URI) is needed. Examples of such are many scenarios where telephony routing with the help of E.164 [E164] numbers according to ENUM [RFC3761], or when an organisation have many domain names, but only one official web page. Faltstrom & Kolkman Expires March 31, 2007 [Page 3] Internet-Draft URI Resource Record September 2006 Applications MUST know the specific service fields to prepend the hostname with. Using repetitive queries for URI records MUST NOT be a replacement for querying for NAPTR or S-NAPTR records. NAPTR and S-NAPTR records are for discovery of the various services and URI for looking up access point for a given service. Those are two very different kinds of needs. 3. DNS considerations Prefixing names with the underscored service tags prevents wildcard based matching [I-D.iab-dns-choices]. Besides, underscored service tags used for the URI RR (based on the NAPTR service descriptions) may have slightly different semantics than service tags used for underscored prefix labels that are used in combination with other (yet unspecified) RR types. This may cause subtle management problems when delegation structure that has developed within the context of URI RRs is also to be used for other RR types. Since the service labels might be overloaded applications should carefully check that the application level protocol is indeed the protocol they expect. Subtle management issues may also arise when the delegations from service to sub service label involves several parties and different stake holders. 4. The format of the URI RR This is the format of the URI RR, whose DNS type code is NNNN (to be assigned by IANA). Ownername TTL Class URI Priority Weight Target 4.1. Ownername, class and type The URI ownername is subject to special conventions. Just like the SRV RR [ref] the URI RR has service information encoded in its ownername. In order to encode the service for a specific owner name one uses service parameters. Valid service parameters used are those as registered by IANA for NAPTR Records of any kind [ref to IANA registry name]. The service parameters are reversed, prepended with an underscore (_) and prepended to the owner name in separate labels. The underscore is prepended to the service parameters to avoid collisions with DNS labels that occur in nature, Faltstrom & Kolkman Expires March 31, 2007 [Page 4] Internet-Draft URI Resource Record September 2006 and the order is reversed to make it possible to do delegations, if needed, to different zones (and therefore providers of DNS). For example, suppose we are looking for the URI for a service with Service Parameter "A:B:C" for host example.com.. Then we would query for (QNAME,QTYPE)=("_C._B._A.example.com","URI") The type number for the URI record is NNNN (to be assigned by IANA). The URI resource record is class independent. The URI RR has no special TTL requirements. 4.2. Priority The priority of this target URI. A client MUST attempt to contact the URI with the lowest-numbered priority it can reach; URIs with the same priority SHOULD be tried in an order defined by the weight field. The range is 0-65535. This is a 16 bit unsigned integer in network byte order. 4.3. Weight A server selection mechanism. The weight field specifies a relative weight for entries with the same priority. Larger weights SHOULD be given a proportionately higher probability of being selected. The range of this number is 0-65535. This is a 16 bit unsigned integer in network byte order. 4.4. Target The URI of the target. Resolution of the URI is according to the definitions for the URI Scheme the URI consists of. The URI is encoded as one or more RFC1035 section 3.3 [RFC1035]. 4.5. URI RDATA Wire Format The RDATA for a URI RR consists of a 2 octet Priority field, a two octet Weight field, and a variable length target field. Faltstrom & Kolkman Expires March 31, 2007 [Page 5] Internet-Draft URI Resource Record September 2006 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Target / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.6. The URI RR Presentation Format The presentation format of the RDATA portion is as follows: Priority field MUST be represented as an unsigned decimal integer. The Weight Type field MUST be represented as an unsigned decimal integer. The target URI is enclosed in double-quotes ("). If the total length of the URI exceeds 255 characters the URI will be encoded in multiple . 5. Definition of the flag 'D' for NAPTR records This document specifies the flag "D" for use as a flag in NAPTR records. The flag indicate a terminal NAPTR record because it denotes the end of the DDDS/NAPTR processing rules. In the case of a "D" flag, the Replacement field in the NAPTR record is used as the Owner of a DNS query for URI records, and normal URI processing as defined in this document is applied. The Regexp field in the NAPTR record MUST be empty when the 'D' flag is in use. 6. Examples 6.1. Homepage at one domain, but two domains in use An organisation have the domain names example.com and example.net, but the official URI http://www.example.com/. Given the Service Tag "web" for the imagined "homepage" application service, the following URI Resource Records could be made available in the respective zones: Faltstrom & Kolkman Expires March 31, 2007 [Page 6] Internet-Draft URI Resource Record September 2006 _web.example.com. IN URI 10 1 "http://www.example.com/" _web.example.net. IN URI 10 1 "http://www.example.com/" 6.2. Different providers for services for the same E.164 An organisation have the E.164 +442079460148, but different organisations handle routing of calls for the number on the Internet (with the help of SIP) and traditional PSTN. More specifically, the two providers want to run DNS for the record(s) that refer to the services they provide. The ENUM provider for the +44 country code in this case not only do delegations on the full E.164 number, but delegations on the service parameter values, as can be seen below: In this example we also include the NAPTR records that with the help of the 'D' flag refer to the URI records. We also include NAPTR records according to RFC 3761 [RFC3761] that give backward compatibility. In zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.: Faltstrom & Kolkman Expires March 31, 2007 [Page 7] Internet-Draft URI Resource Record September 2006 $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. ;; NAPTR records that refer to URI records IN NAPTR 1 1 "D" "E2U:sip" ( ; service "" ; regexp _sip._e2u ; replacement ) IN NAPTR 1 1 "D" "E2U:tel" ( ;service "" ;regexp _tel._e2u ;replacement ) ;; NAPTR records for RFC 3761 compatibility IN NAPTR 1 1 "U" "E2U:sip" ( ;service "!.*!sip:+442079460148@sipprovider.net!" ; regexp . ; replacement ) IN NAPTR 1 1 "U" "E2U:tel" ( ;service "!.*!sip:+442079460148@sipprovider.net!" ; regexp . ; replacement ) ;; Delegations to child zones _sip._e2u IN NS ns1.example.net. _tel._e2u IN NS ns1.example.com. In zone _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa: $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. _sip._e2u IN URI "sip:+442079460148@example.net" In zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa: $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. _tel._e2u IN URI "tel:+442079460148" 7. IANA Considerations 8. Security Considerations Faltstrom & Kolkman Expires March 31, 2007 [Page 8] Internet-Draft URI Resource Record September 2006 9. Acknowledgements Ideas on how to split the two different kind of queries "What services exists for this domain name" and "What is the URI for this service" came from Scott Bradner and Lawrence Conroy. Other people that have contributed to this document include Olafur Gudmundsson, Maria Hall, Peter Koch and Penn Pfautz. 10. References 10.1. Normative References [E164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005. 10.2. Non-normative references [I-D.iab-dns-choices] Faltstrom, P., "Design Choices When Expanding DNS", draft-iab-dns-choices-03 (work in progress), April 2006. [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. Faltstrom & Kolkman Expires March 31, 2007 [Page 9] Internet-Draft URI Resource Record September 2006 Authors' Addresses Patrik Faltstrom Cisco Systems Email: paf@cisco.com Olaf Kolkman NLnet Labs Email: olaf@NLnetLabs.nl Faltstrom & Kolkman Expires March 31, 2007 [Page 10] Internet-Draft URI Resource Record September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Faltstrom & Kolkman Expires March 31, 2007 [Page 11] _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 29 13:35:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMEb-0002wp-Q5; Fri, 29 Sep 2006 13:33:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSjDA-0006Um-PE for enum@ietf.org; Wed, 27 Sep 2006 19:53:08 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSjD9-0008Ei-DY for enum@ietf.org; Wed, 27 Sep 2006 19:53:08 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k8RNrCg6014204 for ; Wed, 27 Sep 2006 16:53:19 -0700 From: "Richard Shockey" To: Date: Wed, 27 Sep 2006 19:52:52 -0400 Message-ID: <005a01c6e290$0cedb1f0$23f0a544@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.2962 Thread-Index: AcbikAtU+PIp+bZ2Qf+FGWKbXR5ORw== 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: de4f315c9369b71d7dd5909b42224370 Subject: [Enum] test please ignore 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 Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz 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 Sep 29 13:35:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMEc-0002x5-28; Fri, 29 Sep 2006 13:33:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSsbz-0006OM-A5 for enum@ietf.org; Thu, 28 Sep 2006 05:55:23 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSsQS-0003Vo-HJ for enum@ietf.org; Thu, 28 Sep 2006 05:43:32 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 28 Sep 2006 02:43:28 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8S9hRPI015426; Thu, 28 Sep 2006 02:43: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 k8S9hRid024978; Thu, 28 Sep 2006 02:43: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 k8S9WesS013233; Thu, 28 Sep 2006 02:32:41 -0700 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: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 28 Sep 2006 11:43:02 +0200 To: IETF ENUM WG X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-5.cisco.com; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=20654; t=1159436607; x=1160300607; c=relaxed/simple; s=sjdkim5002; 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:draft-ietf-enum-uri-00.txt; X=v=3Dcisco.com=3B=20h=3Dgtn+ESeqelsZCSy7NfUKkiq7fXM=3D; b=tjJE/m2+PtFHMW2mvvKmcLZDsIavOi9RUYnCpvnKAL36Y390Six2NliFr7qGRyEAh/vKHivx MxlbiWi2EiStI3twRCp0vuGwRX/AE/WhN3fxUK66lGtNlgLA9lRm14QY; X-Spam-Score: 0.0 (/) X-Scan-Signature: 570a5b81f8c75fea8dcc4c9f6a8a6e54 Subject: [Enum] draft-ietf-enum-uri-00.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 This document was requested to be published the other day, but publication seems to take some time. This is the first document of two that together create RFC 3761bis. Patrik ENUM P. Faltstrom Internet-Draft Cisco Intended status: Standards Track O. Kolkman Expires: March 31, 2007 NLNet September 27, 2006 The Uniform Resource Identifier (URI) DNS Resource Record draft-ietf-enum-uri-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 March 31, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines a new DNS resource record, called the Uniform Resource Identifier (URI) RR, for publishing mappings from hostnames to URIs. Faltstrom & Kolkman Expires March 31, 2007 [Page 1] Internet-Draft URI Resource Record September 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 3. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 4 4. The format of the URI RR . . . . . . . . . . . . . . . . . . . 4 4.1. Ownername, class and type . . . . . . . . . . . . . . . . 4 4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.5. URI RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 4.6. The URI RR Presentation Format . . . . . . . . . . . . . . 6 5. Definition of the flag 'D' for NAPTR records . . . . . . . . . 6 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Homepage at one domain, but two domains in use . . . . . . 6 6.2. Different providers for services for the same E. 164 . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Non-normative references . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Faltstrom & Kolkman Expires March 31, 2007 [Page 2] Internet-Draft URI Resource Record September 2006 1. Introduction This document explains the use of the Domain Name System (DNS) for storage of URIs, and how to resolve hostnames to such URIs that can be used by various applications. For resolution the application need to know both the hostname and the protocol that the URI is to be used for. The protocol is registered by IANA. Currently, looking up URIs given a hostname uses the DDDS [RFC3401] application framework with the DNS as a database as specified in RFC 3404 [RFC3404]. This have a number of implications as described in draft-iab-dns-choices [I-D.iab-dns-choices] such as the inability to select what NAPTR records that match the query is interesting. The RRSet returned will always consist of all URIs "connected" with the domain in question. The URI resource record specified in this document create an ability for the querying party to select which ones of the NAPTR records one is interested in. This because data in the service field of the NAPTR record is included in the owner part of the URI resource record type. Querying for the URI resource record type is not replacing querying for the NAPTR (or S-NAPTR [RFC3958]) resource record type. Instead it is a complementary mechanism to use when one know already what service field is interesting. One can with the URI resource record type directly query for the specific subset of the otherwise possibly large RRSet given back when querying for NAPTR resource records. This document updates RFC 3958 and RFC 3404 by adding the flag "D" to the list of defined terminal flags in section 2.2.3 of RFC 3958 and 4.3 of RFC 3404. 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 BCP 14, RFC 2119 [RFC2119]. 2. Applicability Statement In general, it is expected that URI records will be used by clients for applications where the relevant protocol to be used is known, but for example extra abstraction given by separating a hostname from a point of service (as address by the URI) is needed. Examples of such are many scenarios where telephony routing with the help of E.164 [E164] numbers according to ENUM [RFC3761], or when an organisation have many domain names, but only one official web page. Faltstrom & Kolkman Expires March 31, 2007 [Page 3] Internet-Draft URI Resource Record September 2006 Applications MUST know the specific service fields to prepend the hostname with. Using repetitive queries for URI records MUST NOT be a replacement for querying for NAPTR or S-NAPTR records. NAPTR and S-NAPTR records are for discovery of the various services and URI for looking up access point for a given service. Those are two very different kinds of needs. 3. DNS considerations Prefixing names with the underscored service tags prevents wildcard based matching [I-D.iab-dns-choices]. Besides, underscored service tags used for the URI RR (based on the NAPTR service descriptions) may have slightly different semantics than service tags used for underscored prefix labels that are used in combination with other (yet unspecified) RR types. This may cause subtle management problems when delegation structure that has developed within the context of URI RRs is also to be used for other RR types. Since the service labels might be overloaded applications should carefully check that the application level protocol is indeed the protocol they expect. Subtle management issues may also arise when the delegations from service to sub service label involves several parties and different stake holders. 4. The format of the URI RR This is the format of the URI RR, whose DNS type code is NNNN (to be assigned by IANA). Ownername TTL Class URI Priority Weight Target 4.1. Ownername, class and type The URI ownername is subject to special conventions. Just like the SRV RR [ref] the URI RR has service information encoded in its ownername. In order to encode the service for a specific owner name one uses service parameters. Valid service parameters used are those as registered by IANA for NAPTR Records of any kind [ref to IANA registry name]. The service parameters are reversed, prepended with an underscore (_) and prepended to the owner name in separate labels. The underscore is prepended to the service parameters to avoid collisions with DNS labels that occur in nature, Faltstrom & Kolkman Expires March 31, 2007 [Page 4] Internet-Draft URI Resource Record September 2006 and the order is reversed to make it possible to do delegations, if needed, to different zones (and therefore providers of DNS). For example, suppose we are looking for the URI for a service with Service Parameter "A:B:C" for host example.com.. Then we would query for (QNAME,QTYPE)=("_C._B._A.example.com","URI") The type number for the URI record is NNNN (to be assigned by IANA). The URI resource record is class independent. The URI RR has no special TTL requirements. 4.2. Priority The priority of this target URI. A client MUST attempt to contact the URI with the lowest-numbered priority it can reach; URIs with the same priority SHOULD be tried in an order defined by the weight field. The range is 0-65535. This is a 16 bit unsigned integer in network byte order. 4.3. Weight A server selection mechanism. The weight field specifies a relative weight for entries with the same priority. Larger weights SHOULD be given a proportionately higher probability of being selected. The range of this number is 0-65535. This is a 16 bit unsigned integer in network byte order. 4.4. Target The URI of the target. Resolution of the URI is according to the definitions for the URI Scheme the URI consists of. The URI is encoded as one or more RFC1035 section 3.3 [RFC1035]. 4.5. URI RDATA Wire Format The RDATA for a URI RR consists of a 2 octet Priority field, a two octet Weight field, and a variable length target field. Faltstrom & Kolkman Expires March 31, 2007 [Page 5] Internet-Draft URI Resource Record September 2006 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Target / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.6. The URI RR Presentation Format The presentation format of the RDATA portion is as follows: Priority field MUST be represented as an unsigned decimal integer. The Weight Type field MUST be represented as an unsigned decimal integer. The target URI is enclosed in double-quotes ("). If the total length of the URI exceeds 255 characters the URI will be encoded in multiple . 5. Definition of the flag 'D' for NAPTR records This document specifies the flag "D" for use as a flag in NAPTR records. The flag indicate a terminal NAPTR record because it denotes the end of the DDDS/NAPTR processing rules. In the case of a "D" flag, the Replacement field in the NAPTR record is used as the Owner of a DNS query for URI records, and normal URI processing as defined in this document is applied. The Regexp field in the NAPTR record MUST be empty when the 'D' flag is in use. 6. Examples 6.1. Homepage at one domain, but two domains in use An organisation have the domain names example.com and example.net, but the official URI http://www.example.com/. Given the Service Tag "web" for the imagined "homepage" application service, the following URI Resource Records could be made available in the respective zones: Faltstrom & Kolkman Expires March 31, 2007 [Page 6] Internet-Draft URI Resource Record September 2006 _web.example.com. IN URI 10 1 "http://www.example.com/" _web.example.net. IN URI 10 1 "http://www.example.com/" 6.2. Different providers for services for the same E.164 An organisation have the E.164 +442079460148, but different organisations handle routing of calls for the number on the Internet (with the help of SIP) and traditional PSTN. More specifically, the two providers want to run DNS for the record(s) that refer to the services they provide. The ENUM provider for the +44 country code in this case not only do delegations on the full E.164 number, but delegations on the service parameter values, as can be seen below: In this example we also include the NAPTR records that with the help of the 'D' flag refer to the URI records. We also include NAPTR records according to RFC 3761 [RFC3761] that give backward compatibility. In zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.: Faltstrom & Kolkman Expires March 31, 2007 [Page 7] Internet-Draft URI Resource Record September 2006 $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. ;; NAPTR records that refer to URI records IN NAPTR 1 1 "D" "E2U:sip" ( ; service "" ; regexp _sip._e2u ; replacement ) IN NAPTR 1 1 "D" "E2U:tel" ( ;service "" ;regexp _tel._e2u ;replacement ) ;; NAPTR records for RFC 3761 compatibility IN NAPTR 1 1 "U" "E2U:sip" ( ;service "!.*!sip:+442079460148@sipprovider.net!" ; regexp . ; replacement ) IN NAPTR 1 1 "U" "E2U:tel" ( ;service "!.*!sip:+442079460148@sipprovider.net!" ; regexp . ; replacement ) ;; Delegations to child zones _sip._e2u IN NS ns1.example.net. _tel._e2u IN NS ns1.example.com. In zone _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa: $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. _sip._e2u IN URI "sip:+442079460148@example.net" In zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa: $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. _tel._e2u IN URI "tel:+442079460148" 7. IANA Considerations 8. Security Considerations Faltstrom & Kolkman Expires March 31, 2007 [Page 8] Internet-Draft URI Resource Record September 2006 9. Acknowledgements Ideas on how to split the two different kind of queries "What services exists for this domain name" and "What is the URI for this service" came from Scott Bradner and Lawrence Conroy. Other people that have contributed to this document include Olafur Gudmundsson, Maria Hall, Peter Koch and Penn Pfautz. 10. References 10.1. Normative References [E164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005. 10.2. Non-normative references [I-D.iab-dns-choices] Faltstrom, P., "Design Choices When Expanding DNS", draft-iab-dns-choices-03 (work in progress), April 2006. [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. Faltstrom & Kolkman Expires March 31, 2007 [Page 9] Internet-Draft URI Resource Record September 2006 Authors' Addresses Patrik Faltstrom Cisco Systems Email: paf@cisco.com Olaf Kolkman NLnet Labs Email: olaf@NLnetLabs.nl Faltstrom & Kolkman Expires March 31, 2007 [Page 10] Internet-Draft URI Resource Record September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Faltstrom & Kolkman Expires March 31, 2007 [Page 11] _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 29 13:35:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMEb-0002wp-Q5; Fri, 29 Sep 2006 13:33:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSjDA-0006Um-PE for enum@ietf.org; Wed, 27 Sep 2006 19:53:08 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSjD9-0008Ei-DY for enum@ietf.org; Wed, 27 Sep 2006 19:53:08 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k8RNrCg6014204 for ; Wed, 27 Sep 2006 16:53:19 -0700 From: "Richard Shockey" To: Date: Wed, 27 Sep 2006 19:52:52 -0400 Message-ID: <005a01c6e290$0cedb1f0$23f0a544@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.2962 Thread-Index: AcbikAtU+PIp+bZ2Qf+FGWKbXR5ORw== 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: de4f315c9369b71d7dd5909b42224370 Subject: [Enum] test please ignore 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 Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz 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 Sep 29 13:35:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMEa-0002rx-0g; Fri, 29 Sep 2006 13:33:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSKX2-00056f-HZ for enum@ietf.org; Tue, 26 Sep 2006 17:32:00 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSKX1-0001VP-5p for enum@ietf.org; Tue, 26 Sep 2006 17:32:00 -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 k8QLW4jH026914 for ; Tue, 26 Sep 2006 14:32:09 -0700 From: "Richard Shockey" To: Date: Tue, 26 Sep 2006 17:31:58 -0400 Message-ID: <006001c6e1b3$337f3c90$6e201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbgzpBripZLYt8xTqaD6ilfYSASHAA5GNpQ 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: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Enum] RSEND: ENUM WG Request for Publication - draft-ietf-enum-edns0-00.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 Fyi I did send this out yesterday but I never saw the message hit the = ENUM WG archives. I did get the usual response from the IESG-secretary that = it was received. > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Monday, September 25, 2006 2:15 PM > To: 'iesg-secretary@ietf.org'; 'enum@ietf.org' > Cc: '"Patrik F=E4ltstr=F6m"'; 'Peterson, Jon'; 'Cullen Jennings' > Subject: ENUM WG Request for Publication - = draft-ietf-enum-edns0-00.txt >=20 >=20 >=20 > Title : ENUM Requirement for EDNS0 Support > Author(s) : L. Conroy, J. Reid > Filename : draft-ietf-enum-edns0-00.txt > Pages : 16 > Date : 2006-9-6 >=20 > Support for EDNS0 (Extension Mechanisms for DNS) is mandated in = this > document for DNS entities querying for or serving NAPTR records. = In > general those entities will be supporting ENUM resolution. This > requirement is needed because DNS responses to ENUM-related queries > generally return large RRSets. Without EDNS0 support these lookups > would result in truncated responses and repeated queries over TCP > transport. That has a severe impact on DNS server load and on the > latency of those queries. >=20 > This document adds an operational requirement to use of the = protocol > standardised in RFC 3761. >=20 >=20 >=20 > This is a request for publication for one IETF ENUM WG working group > document. >=20 > A one month WG last call on this document concluded on September 25, = 2006, > 2006. >=20 > The document listed below is being proposed for Best Current Practice. >=20 > There were no additional comments from the last call. >=20 >=20 > Richard Shockey > Director, Member of the Technical Staff > NeuStar > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org > sip:5651(at)neustarlab.biz > PSTN Office +1 571.434.5651 > PSTN Mobile: +1 703.593.2683 > > >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 29 13:35:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMEc-0002xh-KF; Fri, 29 Sep 2006 13:33:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT0GL-0000Jk-Lg for enum@ietf.org; Thu, 28 Sep 2006 14:05:33 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT0GI-0004Wy-EX for enum@ietf.org; Thu, 28 Sep 2006 14:05:33 -0400 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k8SI5PAJ019721 for ; Thu, 28 Sep 2006 18:05:30 GMT From: "Richard Shockey" To: Date: Thu, 28 Sep 2006 14:05:26 -0400 Organization: NeuStar, Inc, Message-ID: <009101c6e328$ae06b530$6e201f0a@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.2962 Thread-Index: AcbjKKyNm6p176O5SNikZXEzf0PYbg== X-Spam-Score: 0.5 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Enum] test -please ignore X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz 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 Sep 29 13:35:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMEa-0002rx-0g; Fri, 29 Sep 2006 13:33:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSKX2-00056f-HZ for enum@ietf.org; Tue, 26 Sep 2006 17:32:00 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSKX1-0001VP-5p for enum@ietf.org; Tue, 26 Sep 2006 17:32:00 -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 k8QLW4jH026914 for ; Tue, 26 Sep 2006 14:32:09 -0700 From: "Richard Shockey" To: Date: Tue, 26 Sep 2006 17:31:58 -0400 Message-ID: <006001c6e1b3$337f3c90$6e201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbgzpBripZLYt8xTqaD6ilfYSASHAA5GNpQ 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: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Enum] RSEND: ENUM WG Request for Publication - draft-ietf-enum-edns0-00.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 Fyi I did send this out yesterday but I never saw the message hit the = ENUM WG archives. I did get the usual response from the IESG-secretary that = it was received. > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Monday, September 25, 2006 2:15 PM > To: 'iesg-secretary@ietf.org'; 'enum@ietf.org' > Cc: '"Patrik F=E4ltstr=F6m"'; 'Peterson, Jon'; 'Cullen Jennings' > Subject: ENUM WG Request for Publication - = draft-ietf-enum-edns0-00.txt >=20 >=20 >=20 > Title : ENUM Requirement for EDNS0 Support > Author(s) : L. Conroy, J. Reid > Filename : draft-ietf-enum-edns0-00.txt > Pages : 16 > Date : 2006-9-6 >=20 > Support for EDNS0 (Extension Mechanisms for DNS) is mandated in = this > document for DNS entities querying for or serving NAPTR records. = In > general those entities will be supporting ENUM resolution. This > requirement is needed because DNS responses to ENUM-related queries > generally return large RRSets. Without EDNS0 support these lookups > would result in truncated responses and repeated queries over TCP > transport. That has a severe impact on DNS server load and on the > latency of those queries. >=20 > This document adds an operational requirement to use of the = protocol > standardised in RFC 3761. >=20 >=20 >=20 > This is a request for publication for one IETF ENUM WG working group > document. >=20 > A one month WG last call on this document concluded on September 25, = 2006, > 2006. >=20 > The document listed below is being proposed for Best Current Practice. >=20 > There were no additional comments from the last call. >=20 >=20 > Richard Shockey > Director, Member of the Technical Staff > NeuStar > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org > sip:5651(at)neustarlab.biz > PSTN Office +1 571.434.5651 > PSTN Mobile: +1 703.593.2683 > > >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 29 13:35:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMEc-0002xh-KF; Fri, 29 Sep 2006 13:33:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT0GL-0000Jk-Lg for enum@ietf.org; Thu, 28 Sep 2006 14:05:33 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT0GI-0004Wy-EX for enum@ietf.org; Thu, 28 Sep 2006 14:05:33 -0400 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k8SI5PAJ019721 for ; Thu, 28 Sep 2006 18:05:30 GMT From: "Richard Shockey" To: Date: Thu, 28 Sep 2006 14:05:26 -0400 Organization: NeuStar, Inc, Message-ID: <009101c6e328$ae06b530$6e201f0a@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.2962 Thread-Index: AcbjKKyNm6p176O5SNikZXEzf0PYbg== X-Spam-Score: 0.5 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Enum] test -please ignore X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz 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 Sep 29 13:35:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMEc-0002xR-BN; Fri, 29 Sep 2006 13:33:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSxo2-0000TW-Dk for enum@ietf.org; Thu, 28 Sep 2006 11:28:10 -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 1GSxar-0000Ue-RX for enum@ietf.org; Thu, 28 Sep 2006 11:14:35 -0400 Received: from [10.10.0.64] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 28 Sep 2006 17:14:19 +0200 id 0007C0DE.451BE6CB.0000288E Message-ID: <451BE65F.9090106@enum.at> Date: Thu, 28 Sep 2006 17:12:31 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: enum@ietf.org Content-Type: multipart/mixed; boundary="------------030101020102070700040508" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Subject: [Enum] [Fwd: Protocol Action: 'IANA Registration for an Enumservice Containing PSTN Signaling Information' to Proposed Standard] 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 is a multi-part message in MIME format. --------------030101020102070700040508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit fyi. --------------030101020102070700040508 Content-Type: message/rfc822; name*0="Protocol Action: 'IANA Registration for an Enumservice Containi"; name*1="ng PSTN Signaling Information' to Proposed Standard" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Protocol Action: 'IANA Registration for an Enumservice Cont"; filename*1="aining PSTN Signaling Information' to Proposed Standard" Received: from megatron.ietf.org (lists.ietf.org [::ffff:156.154.16.145]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 28 Sep 2006 16:04:38 +0200 id 0007C0ED.451BD676.00001D27 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSwHE-0006Tj-Ho; Thu, 28 Sep 2006 09:50:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSwHC-0006TY-A1 for ietf-announce@ietf.org; Thu, 28 Sep 2006 09:50:10 -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 1GSwHC-0000ne-8S for ietf-announce@ietf.org; Thu, 28 Sep 2006 09:50:10 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GSwH9-0006QJ-8I for ietf-announce@ietf.org; Thu, 28 Sep 2006 09:50:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 1DE1D2AC85; Thu, 28 Sep 2006 13:49:37 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GSwGe-0002SV-Sj; Thu, 28 Sep 2006 09:49:36 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 28 Sep 2006 09:49:36 -0400 X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: enum chair , Internet Architecture Board , RFC Editor Subject: Protocol Action: 'IANA Registration for an Enumservice Containing PSTN Signaling Information' to Proposed Standard X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on pahula X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 The IESG has approved the following document: - 'IANA Registration for an Enumservice Containing PSTN Signaling Information ' as a Proposed Standard This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-pstn-05.txt Technical Summary This document defines an enumservice for PSTN routing information. Specifically, it allows the administrator of an ENUM deployment to distinguish records that contain PSTN-specific information (such as number portability data) from records that have a broader utility. For the most part, records that use this enumservice denote resources that must be reached through the PSTN. As such, this enumservice is intended for usage in environments where queries plausibly come from users that are able to benefit from PSTN routing data. Working Group Summary The working group reviewed this document extensively in 2005 and document NIT review was performed by Alexander Mayrhofer Protocol Quality This document was reviewed for the IESG by Jon Peterson. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --------------030101020102070700040508 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 --------------030101020102070700040508-- From enum-bounces@ietf.org Fri Sep 29 13:35:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMEa-0002sT-LB; Fri, 29 Sep 2006 13:33:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSNr5-0002Zr-IU for enum@ietf.org; Tue, 26 Sep 2006 21:04:55 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSNr2-00067C-Dw for enum@ietf.org; Tue, 26 Sep 2006 21:04:55 -0400 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k8R14kAJ026107 for ; Wed, 27 Sep 2006 01:04:52 GMT From: "Richard Shockey" To: Date: Tue, 26 Sep 2006 21:04:40 -0400 Organization: NeuStar, Inc, Message-ID: <006201c6e1d0$edd42bb0$23f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbgzpBripZLYt8xTqaD6ilfYSASHAA5GNpQAAd0jkA= X-Spam-Score: 0.5 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Enum] FW: RSEND: ENUM WG Request for Publication - draft-ietf-enum-edns0-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >=20 > Fyi I did send this out yesterday but I never saw the message hit the = ENUM > WG archives. I did get the usual response from the IESG-secretary that = it > was received. >=20 > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > Sent: Monday, September 25, 2006 2:15 PM > > To: 'iesg-secretary@ietf.org'; 'enum@ietf.org' > > Cc: '"Patrik F=E4ltstr=F6m"'; 'Peterson, Jon'; 'Cullen Jennings' > > Subject: ENUM WG Request for Publication - = draft-ietf-enum-edns0-00.txt > > > > > > > > Title : ENUM Requirement for EDNS0 Support > > Author(s) : L. Conroy, J. Reid > > Filename : draft-ietf-enum-edns0-00.txt > > Pages : 16 > > Date : 2006-9-6 > > > > Support for EDNS0 (Extension Mechanisms for DNS) is mandated in = this > > document for DNS entities querying for or serving NAPTR records. = In > > general those entities will be supporting ENUM resolution. This > > requirement is needed because DNS responses to ENUM-related = queries > > generally return large RRSets. Without EDNS0 support these = lookups > > would result in truncated responses and repeated queries over TCP > > transport. That has a severe impact on DNS server load and on = the > > latency of those queries. > > > > This document adds an operational requirement to use of the = protocol > > standardised in RFC 3761. > > > > > > > > This is a request for publication for one IETF ENUM WG working group > > document. > > > > A one month WG last call on this document concluded on September 25, > 2006, > > 2006. > > > > The document listed below is being proposed for Best Current = Practice. > > > > There were no additional comments from the last call. > > > > > > Richard Shockey > > Director, Member of the Technical Staff > > NeuStar > > 46000 Center Oak Plaza - Sterling, VA 20166 > > sip:rshockey(at)iptel.org > > sip:5651(at)neustarlab.biz > > 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 Sep 29 13:35:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMEa-0002sD-CX; Fri, 29 Sep 2006 13:33:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSNGK-0005yC-E8 for enum@ietf.org; Tue, 26 Sep 2006 20:26:56 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSNGI-0006oz-2K for enum@ietf.org; Tue, 26 Sep 2006 20:26:56 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k8R0Qj1B021141 for ; Tue, 26 Sep 2006 17:26:50 -0700 From: "Richard Shockey" To: Date: Tue, 26 Sep 2006 20:26:26 -0400 Message-ID: <005201c6e1cb$9294bdf0$23f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbgzpBripZLYt8xTqaD6ilfYSASHAA5GNpQAAYeRpA= 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: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Enum] RETRY TEST: ENUM WG Request for Publication - draft-ietf-enum-edns0-00.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 PLEASE IGNORE IF YOU HAVE RECEIVED THIS MESSAGE BEFORE. >=20 > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > Sent: Monday, September 25, 2006 2:15 PM > > To: 'iesg-secretary@ietf.org'; 'enum@ietf.org' > > Cc: '"Patrik F=E4ltstr=F6m"'; 'Peterson, Jon'; 'Cullen Jennings' > > Subject: ENUM WG Request for Publication - = draft-ietf-enum-edns0-00.txt > > > > > > > > Title : ENUM Requirement for EDNS0 Support > > Author(s) : L. Conroy, J. Reid > > Filename : draft-ietf-enum-edns0-00.txt > > Pages : 16 > > Date : 2006-9-6 > > > > Support for EDNS0 (Extension Mechanisms for DNS) is mandated in = this > > document for DNS entities querying for or serving NAPTR records. = In > > general those entities will be supporting ENUM resolution. This > > requirement is needed because DNS responses to ENUM-related = queries > > generally return large RRSets. Without EDNS0 support these = lookups > > would result in truncated responses and repeated queries over TCP > > transport. That has a severe impact on DNS server load and on = the > > latency of those queries. > > > > This document adds an operational requirement to use of the = protocol > > standardised in RFC 3761. > > > > > > > > This is a request for publication for one IETF ENUM WG working group > > document. > > > > A one month WG last call on this document concluded on September 25, > 2006, > > 2006. > > > > The document listed below is being proposed for Best Current = Practice. > > > > There were no additional comments from the last call. > > > > > > Richard Shockey > > Director, Member of the Technical Staff > > NeuStar > > 46000 Center Oak Plaza - Sterling, VA 20166 > > sip:rshockey(at)iptel.org > > sip:5651(at)neustarlab.biz > > 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 Sep 29 13:35:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMEb-0002t0-1J; Fri, 29 Sep 2006 13:33:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSfPu-00011j-2f; Wed, 27 Sep 2006 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSfPt-0006i2-Ox; Wed, 27 Sep 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id AD8F226E52; Wed, 27 Sep 2006 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GSfPt-00038M-Io; Wed, 27 Sep 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: Wed, 27 Sep 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-cnam-04.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 : IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for Media type 'application/cnam' Author(s) : R. Shockey, et al. Filename : draft-ietf-enum-cnam-04.txt Pages : 13 Date : 2006-9-27 This document registers the Enumservice 'pstn' and subtype 'cnam' using the URI scheme 'data:' as per the IANA registration process defined in the ENUM specification, RFC 3761 and registers a new media type application/cnam. This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the Public Switched Telephone Network (PSTN) that may be displayed on VoIP or other Real-time Client User Agents (CUA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-04.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-cnam-04.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-cnam-04.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-9-27124036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-cnam-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-cnam-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-27124036.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 Fri Sep 29 13:35:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMEc-0002xx-Sr; Fri, 29 Sep 2006 13:33:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT1tT-0005mc-2T; Thu, 28 Sep 2006 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT1tS-0003kV-Nf; Thu, 28 Sep 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A08EE26E3B; Thu, 28 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GT1tS-00008e-H4; Thu, 28 Sep 2006 15:50:02 -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, 28 Sep 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-uri-00.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 : The Uniform Resource Identifier (URI) DNS Resource Record Author(s) : P. Faltstrom, O. Kolkman Filename : draft-ietf-enum-uri-00.txt Pages : 11 Date : 2006-9-28 This document defines a new DNS resource record, called the Uniform Resource Identifier (URI) RR, for publishing mappings from hostnames to URIs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-uri-00.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-uri-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-ietf-enum-uri-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. --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-9-28122739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-uri-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-uri-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-28122739.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 Fri Sep 29 13:35:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMEZ-0002rh-Gw; Fri, 29 Sep 2006 13:33:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRv0L-00048E-Ps; Mon, 25 Sep 2006 14:16:33 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRuzb-00012B-89; Mon, 25 Sep 2006 14:15:48 -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 k8PIFnZu018355; Mon, 25 Sep 2006 11:15:54 -0700 From: "Richard Shockey" To: , Date: Mon, 25 Sep 2006 14:15:22 -0400 Message-ID: <016301c6e0ce$91a71990$6e201f0a@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 Thread-Index: AcbgzpBripZLYt8xTqaD6ilfYSASHA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 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: c1c65599517f9ac32519d043c37c5336 Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'=22Patrik_F=E4ltstr=F6m=22'?= , "'Peterson, Jon'" Subject: [Enum] ENUM WG Request for Publication - draft-ietf-enum-edns0-00.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 Requirement for EDNS0 Support Author(s) : L. Conroy, J. Reid Filename : draft-ietf-enum-edns0-00.txt Pages : 16 Date : 2006-9-6 Support for EDNS0 (Extension Mechanisms for DNS) is mandated in this document for DNS entities querying for or serving NAPTR records. In general those entities will be supporting ENUM resolution. This requirement is needed because DNS responses to ENUM-related queries generally return large RRSets. Without EDNS0 support these lookups would result in truncated responses and repeated queries over TCP transport. That has a severe impact on DNS server load and on the latency of those queries. This document adds an operational requirement to use of the protocol standardised in RFC 3761. This is a request for publication for one IETF ENUM WG working group document. A one month WG last call on this document concluded on September 25, 2006, 2006. The document listed below is being proposed for Best Current Practice. There were no additional comments from the last call. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz 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 Sep 29 13:35:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMEb-0002wT-D2; Fri, 29 Sep 2006 13:33:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSgCg-0006Ff-Qh; Wed, 27 Sep 2006 16:40:26 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSgCf-0007FH-Ea; Wed, 27 Sep 2006 16:40:26 -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 k8RKeNkW013608; Wed, 27 Sep 2006 13:40:28 -0700 From: "Richard Shockey" To: , Date: Wed, 27 Sep 2006 16:40:02 -0400 Message-ID: <001d01c6e275$1c9537b0$6e201f0a@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.2962 Thread-Index: AcbidRrsdNW+DQs8QJaqMDsmeXxplw== 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: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'=22Patrik_F=E4ltstr=F6m=22'?= , "'Peterson, Jon'" Subject: [Enum] ENUM WG Request for Publication - draft-ietf-enum-cnam-04.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 : IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for Media type 'application/cnam' Author(s) : R. Shockey, et al. Filename : draft-ietf-enum-cnam-04.txt Pages : 13 Date : 2006-9-27 This document registers the Enumservice 'pstn' and subtype 'cnam' using the URI scheme 'data:' as per the IANA registration process defined in the ENUM specification, RFC 3761 and registers a new media type application/cnam. This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the Public Switched Telephone Network (PSTN) that may be displayed on VoIP or other Real-time Client User Agents (CUA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-04.txt This is a request for publication for one IETF ENUM WG working group document. A one month WG last call on this document concluded on September 25,2006. The document listed below is being proposed for Proposed Standard. This document incorporates numerous comments from the last call. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz 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