From enum-bounces@ietf.org Mon Mar 3 05:45:30 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8794128C688; Mon, 3 Mar 2008 05:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.625 X-Spam-Level: X-Spam-Status: No, score=-0.625 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3iyIMrVT87Z; Mon, 3 Mar 2008 05:45:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF06228C56F; Mon, 3 Mar 2008 05:42:32 -0800 (PST) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3F9E28C562 for ; Mon, 3 Mar 2008 05:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jiu8GdEywDGp for ; Mon, 3 Mar 2008 05:42:26 -0800 (PST) Received: from medel.switch.ch (medel.switch.ch [IPv6:2001:620:0:14:214:4fff:fe75:4774]) by core3.amsl.com (Postfix) with ESMTP id D80D33A6A16 for ; Mon, 3 Mar 2008 05:42:11 -0800 (PST) Received: from [130.59.6.129] (helo=machb.switch.ch) by medel.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JWAvX-0001MK-OV for enum@ietf.org; Mon, 03 Mar 2008 14:41:59 +0100 Date: Mon, 3 Mar 2008 14:41:23 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: enum@ietf.org Message-ID: MIME-Version: 1.0 X-SWITCH-SCANNER: bypassed Subject: [Enum] Enumservices categories (COMMON, X-, P-, ...) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi, While reading RFC3761bis and writing the IANA registration procedures, some idea crossed my mind: To fulfill all the (known) requiements of Enum users, it make sense to split Enumservices in different categories. So far I see a need for three of them: 1. Ordinary (COMMON) registered Enumservices: - Normal IANA Registration procedures apply - No prefix 2. Registered Enumservices for Trial/Experimental: - IANA Registration procedures for Trial/Experimental apply - Prefix: 'X-' 3. Private Enumservices: - Not registered anywhere - Prefix: 'P-' The last category would not need any special standardization document, as IMHO a short definition in RFC3761bis about usage of "P-" in private environment is sufficient. Anybody second this proposal? Objections? cheers, Bernie _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 3 05:55:05 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C972B28C580; Mon, 3 Mar 2008 05:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw9tVdnmPwMp; Mon, 3 Mar 2008 05:55:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296223A6E83; Mon, 3 Mar 2008 05:55:00 -0800 (PST) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CF63A6FAD for ; Mon, 3 Mar 2008 05:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pg8E6nh+C-pZ for ; Mon, 3 Mar 2008 05:54:55 -0800 (PST) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id C5DA03A6E7D for ; Mon, 3 Mar 2008 05:54:55 -0800 (PST) Received: from [192.168.2.144] (220-245-82-41.static.tpgi.com.au [220.245.82.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTP id 922AF4B8073 for ; Tue, 4 Mar 2008 00:54:46 +1100 (EST) Message-ID: <47CC0320.7030805@e164.org> Date: Tue, 04 Mar 2008 00:54:40 +1100 From: Duane User-Agent: Thunderbird 2.0.0.9 (X11/20080214) MIME-Version: 1.0 To: "enum@ietf.org" References: In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Enumservices categories (COMMON, X-, P-, ...) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Bernie Hoeneisen wrote: > 2. Registered Enumservices for Trial/Experimental: > - IANA Registration procedures for Trial/Experimental apply > - Prefix: 'X-' This is already specified for private use in other RFCs, including things non-enum related such as email headers... -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 3 06:29:24 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9C628C567; Mon, 3 Mar 2008 06:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.686 X-Spam-Level: X-Spam-Status: No, score=-0.686 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOGBRSNCxqSl; Mon, 3 Mar 2008 06:29:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB25628C59A; Mon, 3 Mar 2008 06:29:18 -0800 (PST) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 852C528C4CC for ; Mon, 3 Mar 2008 06:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWqBTer4oI7Z for ; Mon, 3 Mar 2008 06:29:12 -0800 (PST) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id EAA4528C5B9 for ; Mon, 3 Mar 2008 06:29:11 -0800 (PST) Received: from [127.0.0.1] (norman.insensate.co.uk [213.152.49.123]) by insensate.co.uk (Postfix) with ESMTP id 3B03D8162A; Mon, 3 Mar 2008 14:29:22 +0000 (GMT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <87F1671A-4AD9-4A26-B411-62A6CDDD9C91@insensate.co.uk> From: lconroy Date: Mon, 3 Mar 2008 14:29:01 +0000 To: Bernie Hoeneisen X-Mailer: Apple Mail (2.753) Cc: enum@ietf.org Subject: Re: [Enum] Enumservices categories (COMMON, X-, P-, ...) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Bernie, folks, this will require a small update to the current version of RFC 3761bis, but IMHO is a very good plan. If one sees such a "P-xxxx" Enumservice on the Internet, then it SHOULD be ignored. I like this idea. It also codifies the idea that stuff floating around on a private infrastructure does not need to be specified other than between those "consenting networks". This is different from X-xxx, where at least a notification that it is being used (with some optional information on what it does) is preferred - to summarise my understanding of the position at the YVR ENUM WG meeting. all the best, Lawrence On 3 Mar 2008, at 13:41, Bernie Hoeneisen wrote: > Hi, > > While reading RFC3761bis and writing the IANA registration > procedures, some idea crossed my mind: > > To fulfill all the (known) requiements of Enum users, it make sense to > split Enumservices in different categories. So far I see a need for > three > of them: > > 1. Ordinary (COMMON) registered Enumservices: > - Normal IANA Registration procedures apply > - No prefix > > 2. Registered Enumservices for Trial/Experimental: > - IANA Registration procedures for Trial/Experimental apply > - Prefix: 'X-' > > 3. Private Enumservices: > - Not registered anywhere > - Prefix: 'P-' > > The last category would not need any special standardization > document, as > IMHO a short definition in RFC3761bis about usage of "P-" in private > environment is sufficient. > > Anybody second this proposal? > > Objections? > > cheers, > Bernie > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 3 08:29:26 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D7A43A6A29; Mon, 3 Mar 2008 08:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3zbUKVaA4Su; Mon, 3 Mar 2008 08:29:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691F43A6AAF; Mon, 3 Mar 2008 08:29:18 -0800 (PST) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3879C28C1AE for ; Mon, 3 Mar 2008 08:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmLfOdeywBoE for ; Mon, 3 Mar 2008 08:29:10 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 5C78F28C23C for ; Mon, 3 Mar 2008 08:28:19 -0800 (PST) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m23GRKYp022408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Mar 2008 08:27:22 -0800 From: "Richard Shockey" To: "'lconroy'" , "'Bernie Hoeneisen'" References: <87F1671A-4AD9-4A26-B411-62A6CDDD9C91@insensate.co.uk> In-Reply-To: <87F1671A-4AD9-4A26-B411-62A6CDDD9C91@insensate.co.uk> Date: Mon, 3 Mar 2008 11:27:59 -0500 Message-ID: <01a901c87d4b$8caa2840$a5fe78c0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ach9Ot0JjZDGbkZ4T6KuCcA6H3nWMAAEJl/w Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: enum@ietf.org Subject: Re: [Enum] Enumservices categories (COMMON, X-, P-, ...) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Chair hat off .. Makes sense to me ! I like it too... > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of lconroy > Sent: Monday, March 03, 2008 9:29 AM > To: Bernie Hoeneisen > Cc: enum@ietf.org > Subject: Re: [Enum] Enumservices categories (COMMON, X-, P-, ...) > > Hi Bernie, folks, > > this will require a small update to the current version of RFC > 3761bis, but IMHO > is a very good plan. If one sees such a "P-xxxx" Enumservice on the > Internet, then > it SHOULD be ignored. I like this idea. > > It also codifies the idea that stuff floating around on a private > infrastructure > does not need to be specified other than between those "consenting > networks". > > This is different from X-xxx, where at least a notification that it > is being used > (with some optional information on what it does) is preferred - to > summarise my > understanding of the position at the YVR ENUM WG meeting. > > all the best, > Lawrence > > On 3 Mar 2008, at 13:41, Bernie Hoeneisen wrote: > > Hi, > > > > While reading RFC3761bis and writing the IANA registration > > procedures, some idea crossed my mind: > > > > To fulfill all the (known) requiements of Enum users, it make sense > to > > split Enumservices in different categories. So far I see a need for > > three > > of them: > > > > 1. Ordinary (COMMON) registered Enumservices: > > - Normal IANA Registration procedures apply > > - No prefix > > > > 2. Registered Enumservices for Trial/Experimental: > > - IANA Registration procedures for Trial/Experimental apply > > - Prefix: 'X-' > > > > 3. Private Enumservices: > > - Not registered anywhere > > - Prefix: 'P-' > > > > The last category would not need any special standardization > > document, as > > IMHO a short definition in RFC3761bis about usage of "P-" in private > > environment is sufficient. > > > > Anybody second this proposal? > > > > Objections? > > > > cheers, > > Bernie > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 3 12:06:48 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E4F3A6E03; Mon, 3 Mar 2008 12:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.086 X-Spam-Level: X-Spam-Status: No, score=-1.086 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IDoCdNnbc5D; Mon, 3 Mar 2008 12:06:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B85128C160; Mon, 3 Mar 2008 12:06:31 -0800 (PST) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4673A3A6E94 for ; Mon, 3 Mar 2008 12:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KIak13Ord0C for ; Mon, 3 Mar 2008 12:06:23 -0800 (PST) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 498523A6BBF for ; Mon, 3 Mar 2008 12:02:46 -0800 (PST) Received: from [192.168.2.144] (220-245-82-41.static.tpgi.com.au [220.245.82.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTP id 2DB2C4B8003 for ; Tue, 4 Mar 2008 07:02:36 +1100 (EST) Message-ID: <47CC5954.6060307@e164.org> Date: Tue, 04 Mar 2008 07:02:28 +1100 From: Duane User-Agent: Thunderbird 2.0.0.9 (X11/20080214) MIME-Version: 1.0 To: "enum@ietf.org" References: <87F1671A-4AD9-4A26-B411-62A6CDDD9C91@insensate.co.uk> <01a901c87d4b$8caa2840$a5fe78c0$@us> In-Reply-To: <01a901c87d4b$8caa2840$a5fe78c0$@us> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Enumservices categories (COMMON, X-, P-, ...) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard Shockey wrote: > Chair hat off .. > > Makes sense to me ! I like it too... Does it make sense to re-use something in common usage in email to create an inconsistency as well? -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 3 14:39:24 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED0DE28C2EA; Mon, 3 Mar 2008 14:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-AUYeGpgu4Z; Mon, 3 Mar 2008 14:39:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43D4D3A69FE; Mon, 3 Mar 2008 14:39:19 -0800 (PST) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D99673A6780 for ; Mon, 3 Mar 2008 14:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd-tauV+Xels for ; Mon, 3 Mar 2008 14:39:13 -0800 (PST) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 51A623A6BF5 for ; Mon, 3 Mar 2008 14:39:13 -0800 (PST) Received: from [127.0.0.1] (norman.insensate.co.uk [213.152.49.123]) by insensate.co.uk (Postfix) with ESMTP id 4EA2881884; Mon, 3 Mar 2008 22:39:24 +0000 (GMT) In-Reply-To: <47CC5954.6060307@e164.org> References: <87F1671A-4AD9-4A26-B411-62A6CDDD9C91@insensate.co.uk> <01a901c87d4b$8caa2840$a5fe78c0$@us> <47CC5954.6060307@e164.org> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: lconroy Date: Mon, 3 Mar 2008 22:39:02 +0000 To: Duane X-Mailer: Apple Mail (2.753) Cc: "enum@ietf.org" Subject: Re: [Enum] Enumservices categories (COMMON, X-, P-, ...) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Dwayne, folks, Short answer is: Yes, because it isn't. The issue is not confusion with mail headers. There is a difference between email headers (or even old-style proprietary MIME types) and Enumservices inside NAPTRs. We already have X- Enumservices. We have had these since RFC 3761. To avoid clashes, we invite folk to at least tell people what Enumservices they use on the Internet, and optionally to tell them what these Enumservices do. (Yes - this invitation is intended for everyone - including me and you :). The proposal (for P- Enumservices) is quite different. These are Enumservices that should never be on the Internet - no-one outside the walled garden should see them. If a client DOES encounter one, it should be ignored. The URI may not be interpretable outside the walled garden, so even if you think you know what the Enumservice does, don't try it at home. Contrast this with a NAPTR containing x-voice, or x-im, or whatever. I know how to handle that, it hasn't escaped from a zoo, and so I can use it, out there on the Internet. Seems to me like P- is the hidden piece in the puzzle. all the best, Lawrence On 3 Mar 2008, at 20:02, Duane wrote: > Richard Shockey wrote: >> Chair hat off .. >> >> Makes sense to me ! I like it too... > > Does it make sense to re-use something in common usage in email to > create an inconsistency as well? > > -- > > Best regards, > Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Mar 4 01:13:44 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B46828C491; Tue, 4 Mar 2008 01:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.634 X-Spam-Level: X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6LUWRTnI131; Tue, 4 Mar 2008 01:13:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E224E3A6EE9; Tue, 4 Mar 2008 01:13:38 -0800 (PST) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473E23A6EFF for ; Tue, 4 Mar 2008 01:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X65tkfdiZdwk for ; Tue, 4 Mar 2008 01:13:31 -0800 (PST) Received: from medel.switch.ch (medel.switch.ch [IPv6:2001:620:0:14:214:4fff:fe75:4774]) by core3.amsl.com (Postfix) with ESMTP id 7E9E43A6EE5 for ; Tue, 4 Mar 2008 01:13:31 -0800 (PST) Received: from [130.59.6.129] (helo=machb.switch.ch) by medel.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JWTD3-000671-NX; Tue, 04 Mar 2008 10:13:17 +0100 Date: Tue, 4 Mar 2008 10:12:40 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: lconroy In-Reply-To: Message-ID: References: <87F1671A-4AD9-4A26-B411-62A6CDDD9C91@insensate.co.uk> <01a901c87d4b$8caa2840$a5fe78c0$@us> <47CC5954.6060307@e164.org> MIME-Version: 1.0 X-SWITCH-SCANNER: bypassed Cc: "enum@ietf.org" , Duane Subject: Re: [Enum] Enumservices categories (COMMON, X-, P-, ...) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Duane et al. On Mon, 3 Mar 2008, lconroy wrote: > The issue is not confusion with mail headers. There is a difference > between email headers (or even old-style proprietary MIME types) and > Enumservices inside NAPTRs. I also do not see any dependency issue between ENUM NAPTR types and other codepoints. For example SMTP does not have a too clear concept for mail headers (IMHO), i.e. 'X-' is used for different purposes: 1) widely used headers e.g. X-BeenThere, X-Mailer 2) private style headers e.g. X-MyCom-MailScanner-SpamCheck, X-Google-Sender-Auth Should we really blindly take over concepts discovered to be problematic elsewhere just for the sake of consistency? I'd say, Bad Idea! > The proposal (for P- Enumservices) is quite different. These are > Enumservices that should never be on the Internet - no-one outside the > walled garden should see them. I guess it cannot be avoided that P- Enumservices appear outside the walled garden. After all, it is in DNS, which normally is public. Therefore the direction "clients SHOULD ignore them, if not part of to walled garden" is rather important. > If a client DOES encounter one, it should be ignored. The URI may not be > interpretable outside the walled garden, so even if you think you know > what the Enumservice does, don't try it at home. cheers, Bernie _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Mar 4 11:54:37 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C6628C535; Tue, 4 Mar 2008 11:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAAiO0U93iaE; Tue, 4 Mar 2008 11:54:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE9828C498; Tue, 4 Mar 2008 11:54:36 -0800 (PST) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A634828C536 for ; Tue, 4 Mar 2008 11:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcZ5CTi0Sjwm for ; Tue, 4 Mar 2008 11:54:33 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id ABD1A3A6CBF for ; Tue, 4 Mar 2008 11:54:33 -0800 (PST) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m24JrOhl031891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 4 Mar 2008 11:53:25 -0800 From: "Richard Shockey" To: Date: Tue, 4 Mar 2008 14:54:00 -0500 Message-ID: <023f01c87e31$7e6a1d80$7b3e5880$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ach+MX132UscYuxoS7u6k9DkFRa4/w== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [Enum] ENUM Final Agenda. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Most of the time probably should be spent on RFC 3761 and any last issues in the ENUM Service Registration documents etc. **************************** IETF 71 Telephone Number Mapping (ENUM) WG Agenda THURSDAY, March 13, 2008 1510-1610 Afternoon Session II Franklin 3/4 INT savi Source Address Validation Improvements BOF Franklin 11/12 RAI avt Audio/Video Transport WG Franklin 6/7 RAI enum Telephone Number Mapping WG Salon I SEC smime S/MIME Mail Security WG Chair(s): Patrik Faltstrom Richard Shockey WG Secretary: Alexander Mayrhofer RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com RAI Area Advisor: Jon Peterson jon.peterson@neustar.biz Agenda Bashing. 1. Status of Drafts and in Drafts the Queue Overview - Alexander Mayhofer WG Secretary 10 2. Title : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) Author(s) : S. Bradner, et al. Filename : draft-ietf-enum-3761bis-02.txt Pages : 20 Date : 2008-02-13 This document discusses the use of the Domain Name System (DNS) for the storage of E.164 numbers, and for resolving them into URIs that can be used for (for example) telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-3761bis-02.txt CHAIR NOTE: Some guidance on the issue of P- Enumservices might be helpful as well. 3. Title : IANA Registration of Enumservices: Guide, Template and IANA Considerations Author(s) : B. Hoeneisen, et al. Filename : draft-ietf-enum-enumservices-guide-07.txt Pages : 36 Date : 2008-02-25 This document specifies a revision of the IANA registry for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservices and its Registration Documents. Registration of Enumservices is now handled using the "Expert Review" process. A Registration Document containing the specification of the Enumservice is required. However, contrary to earlier registration procedures, said Registration Document does not necessarily need to be promoted to RFC status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-07.tx t 4. Title : DNS Extension for ENUM Source-URI Author(s) : H. Kaplan, et al. Filename : draft-kaplan-enum-source-uri-00.txt Pages : 8 Date : 2007-12-11 This document defines a specific DNS extension, based on the EDNS0 OPT RR, for an ENUM query to include the source URI which caused the ENUM request. This is useful, for example, to specify the originating SIP or TEL URI from a SIP request which triggered the ENUM query, so the ENUM server can provide a different response. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Mar 5 11:46:49 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 110EA3A6F20; Wed, 5 Mar 2008 11:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.194 X-Spam-Level: X-Spam-Status: No, score=-0.194 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XJB4MXK8TRb; Wed, 5 Mar 2008 11:46:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F58C3A6ADF; Wed, 5 Mar 2008 11:46:48 -0800 (PST) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4B428C8C5 for ; Wed, 20 Feb 2008 23:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Afhc2W-IHhZZ for ; Wed, 20 Feb 2008 23:13:17 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 300B928C975 for ; Wed, 20 Feb 2008 23:12:51 -0800 (PST) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.41 ; Thu, 21 Feb 2008 08:12:45 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 21 Feb 2008 08:12:45 +0100 Message-ID: <8BC845943058D844ABFC73D2220D4665071ECC45@nics-mail.sbg.nic.at> In-Reply-To: <097401c873e7$c16b6660$44423320$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] PRELIMINARY AGENDA ENUM WG Thread-Index: Achz58B9CZWEwhUHRIWDeRJohSbTaQAcPv/g References: <097401c873e7$c16b6660$44423320$@us> From: "Alexander Mayrhofer" To: "Richard Shockey" X-Mailman-Approved-At: Wed, 05 Mar 2008 11:46:46 -0800 Cc: enum@ietf.org, Bernie Hoeneisen Subject: Re: [Enum] PRELIMINARY AGENDA ENUM WG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > Did we want to finalize discussion of the enum Registration document? We'll definitely need some time in the session for that. Our plan is to iron out things over the week already, so that we make best use of the available time. It now looks as if this document would have to be published together with 3671bis. We'll post a new revision soon, likely tomorrow. cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Mar 6 03:39:41 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EBAF3A6F07; Thu, 6 Mar 2008 03:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.686 X-Spam-Level: X-Spam-Status: No, score=-100.686 tagged_above=-999 required=5 tests=[AWL=-1.249, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xCGnIz1v8-D; Thu, 6 Mar 2008 03:39:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE81A28C8CB; Thu, 6 Mar 2008 03:39:17 -0800 (PST) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37CB928C89C for ; Thu, 6 Mar 2008 03:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+EYn11Hn5cT for ; Thu, 6 Mar 2008 03:39:11 -0800 (PST) Received: from mail2.pts.se (mail2.pts.se [192.121.211.220]) by core3.amsl.com (Postfix) with ESMTP id 25E0228C10E for ; Thu, 6 Mar 2008 03:38:33 -0800 (PST) Received: from safir.pts.se (safir.pts.ad [192.121.215.23]) by mail2.pts.se (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 6 Mar 2008 12:38:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 12:38:21 +0100 Message-ID: <8FA68CE33018BF46B863699DB9D2DD010AF6B0@safir.pts.ad> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on RFC3761bis - draft-ietf-enum-3761bis-02.txt Thread-Index: Ach/fpRoW4smqVDfTpK28PdcjE0Ihw== From: To: , , Cc: enum@ietf.org, Bo.Martinsson@pts.se, grichena@telcordia.com, Christoffer.Karsberg@pts.se, tony.ar.holmes@bt.com, richard.hill@itu.int, staffan.hagnell@iis.se, rich.shockey@neustar.biz, Susanne.Lindstrom-Chennell@pts.se, paf@cisco.com, tsg2q1@ties.itu.int, niclas.rosell@iis.se Subject: [Enum] Comments on RFC3761bis - draft-ietf-enum-3761bis-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1327246169==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1327246169== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87F7E.95217AE5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87F7E.95217AE5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: the authors of RFC 3761bis (sob@harvard.edu, lconroy@insensate.co.uk = and fujiwara@jprs.co.jp) =20 =20 cc: mailinglist IETF ENUM WG (enum@ietf.org) and mailinglist ITU-T SG2 = Q1/2 (tsg2q1@ties.itu.int) =20 =20 I would like to provide a comment on the draft version of RFC3761bis = (draft-ietf-enum-3761bis-02.txt) sent out 2008-02-14 via = Internet-Drafts@ietf.org. I can not attend the IETF meeting next week = (71 st IETF in the USA) but hope that this comment anyway can be = resloved. =20 My concern is that the text from RFC 3761 under IANA Consideration about = delegation of domains on country level and the relationship between IAB = and ITU TSB (and indirect with the RIPE NCC) is missing. All this text, = that I think is important, is now deleted in the draft version of RFC = 3761bis. Similar kind of text could not be found in the referenced = document in clause 6 [SV_GUIDE] (draft-ietf-enum-enumservices-guide-07) = of RFC 3761bis. =20 The missing text of importance is reproduced below taken from RFC 3761: =20 "5. IANA Considerations =20 RFC 2916 (which this document replaces) requested IANA to delegate the E164.ARPA domain following instructions to be provided by the IAB. The domain was delegated according to those instructions. Names within this zone are to be delegated to parties according to the ITU-T Recommendation E.164. The names allocated should be hierarchic in accordance with ITU-T Recommendation E.164, and the codes should be assigned in accordance with that Recommendation. =20 IAB is to coordinate with ITU-T TSB if the technical contact for the domain e164.arpa is to change, as ITU-T TSB has an operational working relationship with this technical contact which needs to be reestablished. =20 Delegations in the zone e164.arpa (not delegations in delegated domains of e164.arpa) should be done after Expert Review, and the IESG will appoint a designated expert." =20 I think it=B4s important to have this kind of statement in RFC 3761bis. = If not I think procedures in the IAB instructions = (http://www.ripe.net/enum/instructions.html) to RIPE NCC have to be = revised and also the ITU Interim procedures = (http://www.itu.int/ITU-T/inr/enum/procedures.html) for ENUM = delegations.=20 =20 If this text not will be re-entered I also think that RFC 3761bis will = in some part obsoletes RFC 3245 (The History and Context of Telephone = Number Mapping (ENUM) Operational Decisions: Informational Documents = Contributed to ITU-T Study Group 2 (SG2)). =20 Besides my more important comment above I also have some minor comments = on draft RFC 3761bis but I might provide them at a later stage. =20 =20 Sincerely =20 =20 Joakim Str=E5lmark Senior Adviser Swedish Post and Telecom Agency, PTS Network Security Department Security and Addressing Phone: +46 8 678 55 69 Mobile: +46 70 811 40 64 joakim.stralmark@pts.se =20 www.pts.se =20 ------_=_NextPart_001_01C87F7E.95217AE5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

To: the = authors of RFC 3761bis (sob@harvard.edu, lconroy@insensate.co.uk and = fujiwara@jprs.co.jp)=A0 =

 =

cc: = mailinglist IETF ENUM WG (enum@ietf.org) and = mailinglist ITU-T SG2 Q1/2 (tsg2q1@ties.itu.int)

=A0=A0=A0

 

I would like to provide a comment on the draft = version of RFC3761bis (draft-ietf-enum-3761bis-02.txt) sent out 2008-02-14 via Internet-Drafts@ietf.org. I = can not attend the IETF meeting next week (71 st IETF in the USA) but hope that = this comment anyway can be resloved.

 

My concern is that the text from RFC 3761 under = IANA Consideration about delegation of domains on country level and the = relationship between IAB and ITU TSB (and indirect with the RIPE NCC) is missing. All = this text, that I think is important, is now deleted in the draft version of = RFC 3761bis. Similar kind of text could not be found in the referenced = document in clause 6 [SV_GUIDE] (draft-ietf-enum-enumservices-guide-07) of RFC = 3761bis.

 

The missing text of importance is reproduced below = taken from RFC 3761:

 

”5.=A0 IANA = Considerations

 

=A0=A0 RFC 2916 (which = this document replaces) requested IANA to delegate

=A0=A0 the E164.ARPA = domain following instructions to be provided by the

=A0=A0 IAB.=A0 The domain = was delegated according to those instructions.

=A0=A0 Names within this = zone are to be delegated to parties according to

=A0=A0 the ITU-T = Recommendation E.164.=A0 The names allocated should be

=A0=A0 hierarchic in = accordance with ITU-T Recommendation E.164, and the

=A0=A0 codes should be = assigned in accordance with that Recommendation.

 

=A0=A0 IAB is to = coordinate with ITU-T TSB if the technical contact for the

=A0=A0 domain e164.arpa is = to change, as ITU-T TSB has an operational

=A0=A0 working = relationship with this technical contact which needs to be

=A0=A0 = reestablished.

 

=A0=A0 Delegations in the = zone e164.arpa (not delegations in delegated

=A0=A0 domains of = e164.arpa) should be done after Expert Review, and the

=A0=A0 IESG will appoint a = designated expert.”

 

I think it=B4s important to have this kind of = statement in RFC 3761bis. If not I think procedures in the IAB instructions (http://www.ripe.net/e= num/instructions.html) to RIPE NCC have to be revised and also the ITU Interim procedures (http://www.itu= .int/ITU-T/inr/enum/procedures.html) for ENUM delegations.

 

If this text not will be re-entered I also think = that RFC 3761bis will in some part obsoletes RFC 3245 (The History and Context of Telephone Number Mapping (ENUM) Operational = Decisions: Informational Documents Contributed to ITU-T Study Group 2 = (SG2)).

 

Besides my more important comment above I also have = some minor comments on draft RFC 3761bis but I might provide them at a later = stage.

 

 

Sincerely

 

 

Joakim Str=E5lmark
Senior Adviser

Swedish Post and Telecom Agency, PTS
Network Security Department
Security and Addressing

Phone: +46 8 678 55 69
Mobile: +46 70 811 40 64
joakim.stralmark@pts.se
www.pts.se

------_=_NextPart_001_01C87F7E.95217AE5-- --===============1327246169== 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://www.ietf.org/mailman/listinfo/enum --===============1327246169==-- From enum-bounces@ietf.org Mon Mar 10 07:11:18 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE0062939D2; Mon, 10 Mar 2008 07:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Immy2M4jDTbP; Mon, 10 Mar 2008 07:11:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8263E293924; Mon, 10 Mar 2008 06:00:09 -0700 (PDT) X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4804D293915; Mon, 10 Mar 2008 06:00:03 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080310130004.4804D293915@core3.amsl.com> Date: Mon, 10 Mar 2008 06:00:04 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] I-D Action:draft-ietf-enum-calendar-service-04.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services Author(s) : R. Mahy Filename : draft-ietf-enum-calendar-service-04.txt Pages : 7 Date : 2008-03-10 This document registers a Telephone Number Mapping (ENUM) service for Internet Calendaring Services. Specifically, this document focuses on provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-enum-calendar-service-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-03-10055311.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Mon Mar 10 13:15:03 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B993A6DAD; Mon, 10 Mar 2008 13:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.269 X-Spam-Level: X-Spam-Status: No, score=-102.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWoBPaYqhS2N; Mon, 10 Mar 2008 13:15:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3CF43A6B77; Mon, 10 Mar 2008 13:15:01 -0700 (PDT) X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4A2AB3A6CD0; Mon, 10 Mar 2008 13:15:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080310201501.4A2AB3A6CD0@core3.amsl.com> Date: Mon, 10 Mar 2008 13:15:01 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] I-D Action:draft-ietf-enum-enumservices-guide-08.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org 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 of Enumservices: Guide, Template and IANA Considerations Author(s) : B. Hoeneisen, et al. Filename : draft-ietf-enum-enumservices-guide-08.txt Pages : 37 Date : 2008-03-10 This document specifies a revision of the IANA registry for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservices and its Registration Documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-enum-enumservices-guide-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-03-10130738.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Mon Mar 10 13:20:32 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E749C28C2C0; Mon, 10 Mar 2008 13:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSpAU-KX9WML; Mon, 10 Mar 2008 13:20:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2CF3A6DD8; Mon, 10 Mar 2008 13:20:28 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4373A6DD0 for ; Mon, 10 Mar 2008 13:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsoZkAaOWv9w for ; Mon, 10 Mar 2008 13:20:27 -0700 (PDT) Received: from kahua.nona.net (pahula.nona.net [193.80.224.123]) by core3.amsl.com (Postfix) with ESMTP id 075F628C104 for ; Mon, 10 Mar 2008 13:20:23 -0700 (PDT) Received: from [130.129.19.151] ([::ffff:130.129.19.151]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Mon, 10 Mar 2008 21:16:39 +0100 id 0000C0F7.47D59728.000044E5 Message-ID: <47D59768.4070906@enum.at> Date: Mon, 10 Mar 2008 21:17:44 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_pahula-17637-1205180200-0001-2" To: enum@ietf.org Subject: [Enum] [Fwd: I-D Action:draft-ietf-enum-enumservices-guide-08.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_pahula-17637-1205180200-0001-2 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI: We did a couple of changes to the Enumservices document - this is supposed to be the basis for any discussions on Thursday.. changes from -07 (see appendix B): draft-ietf-enum-enumservices-guide-08: o alex: new text for subtypes of protocol class enumservices ("mandatory to implement" stuff) o alex: added "to be foreseen" to the application type subtype recommendation o alex: added "lowercase" recommendation to the type names o bernie: Corrected various typos, clarifications, and other editorial stuff (feedback from Lawrence Conroy) o bernie: IANA Registry ftp -> http (feedback from Lawrence Conroy) o bernie: Made steps prior to IANA submission mandatory (feedback from Lawrence Conroy) o bernie: Shortened abstract (Note to Lawrence/Peter: We didn't add anything regarding "X-" and "P-" services yet).. cheers Alex -------- Original Message -------- Subject: I-D Action:draft-ietf-enum-enumservices-guide-08.txt Date: Mon, 10 Mar 2008 13:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: enum@ietf.org 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 of Enumservices: Guide, Template and IANA Considerations Author(s) : B. Hoeneisen, et al. Filename : draft-ietf-enum-enumservices-guide-08.txt Pages : 37 Date : 2008-03-10 This document specifies a revision of the IANA registry for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservices and its Registration Documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --=_pahula-17637-1205180200-0001-2 Content-Type: message/external-body; name="draft-ietf-enum-enumservices-guide-08.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-enum-enumservices-guide-08.txt" Content-Type: text/plain Content-ID: <2008-03-10130738.I-D@ietf.org> --=_pahula-17637-1205180200-0001-2 Content-Type: text/plain; name="file:///C:/DOKUME~1/ALEX/LOKALE~1/TEMP/nsmail-1.txt"; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///C:/DOKUME~1/ALEX/LOKALE~1/TEMP/nsmail-1.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --=_pahula-17637-1205180200-0001-2 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://www.ietf.org/mailman/listinfo/enum --=_pahula-17637-1205180200-0001-2-- From enum-bounces@ietf.org Mon Mar 10 15:24:00 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B7628C11A; Mon, 10 Mar 2008 15:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPgHUN4yQRxJ; Mon, 10 Mar 2008 15:24:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2503A6B8D; Mon, 10 Mar 2008 15:23:59 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DAE53A6C91 for ; Mon, 10 Mar 2008 15:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIjrWTq6WWHD for ; Mon, 10 Mar 2008 15:23:57 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id CB9723A696A for ; Mon, 10 Mar 2008 15:23:57 -0700 (PDT) Received: from rshockeyPC (dhcp-160d.ietf71.ietf.org [130.129.22.13]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m2AMKRV6001340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Mar 2008 14:20:32 -0800 From: "Richard Shockey" To: Date: Mon, 10 Mar 2008 18:21:04 -0400 Message-ID: <04e801c882fd$0ea54cb0$2befe610$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciC/QewL3LKywEjQwq4y0YtFeNAGQ== Content-language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: 'Alexander Mayrhofer' Subject: [Enum] SLIDES PLEASE... X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org PLEASE send your slides to Alexander or me ASAP. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Mar 12 08:24:39 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61EFC28C658; Wed, 12 Mar 2008 08:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.111 X-Spam-Level: X-Spam-Status: No, score=-100.111 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1nBu2VH80U7; Wed, 12 Mar 2008 08:24:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4666E28C241; Wed, 12 Mar 2008 08:24:31 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3982328C658 for ; Wed, 12 Mar 2008 08:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4FQcfwMxuuu for ; Wed, 12 Mar 2008 08:24:25 -0700 (PDT) Received: from kahua.nona.net (pahula.nona.net [193.80.224.123]) by core3.amsl.com (Postfix) with ESMTP id A948B28C241 for ; Wed, 12 Mar 2008 08:24:16 -0700 (PDT) Received: from [130.129.21.190] ([::ffff:130.129.21.190]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 12 Mar 2008 16:19:59 +0100 id 00038026.47D7F4A0.0000126D Message-ID: <47D7F505.4080808@enum.at> Date: Wed, 12 Mar 2008 16:21:41 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: enum@ietf.org, rohan@ekabal.com Subject: [Enum] comment on draft-ietf-enum-calendar-service-04 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi, i'm a bit hesitant about the "sched" subtype being used for both iMIP and CalDAV. Essentially that would mean that any ical:sched capable client would need to support both protocols, because it must not select a NAPTR by looking at the URI scheme... Is that intended? An alternative would be to define seperate subtypes for iMIP and CalDAV scheduling protocols, so that a client which does not support CalDAV does not "run" into a URI scheme that it cannot use. Actually this might even be a use case for those nasty "sub-sub-Types" ("ical:sched:imip" and "ical:sched:caldav", but i'm pretty sure we don't want to go down this road, do we? comments? Alex _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Mar 12 11:04:32 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D1F28C6F0; Wed, 12 Mar 2008 11:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.797 X-Spam-Level: X-Spam-Status: No, score=-100.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4COmbIcsl7y; Wed, 12 Mar 2008 11:04:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE71628C625; Wed, 12 Mar 2008 11:04:31 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2AAC28C625 for ; Wed, 12 Mar 2008 11:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuRNIoREyXMH for ; Wed, 12 Mar 2008 11:04:30 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 1840528C462 for ; Wed, 12 Mar 2008 11:04:29 -0700 (PDT) Received: from [192.168.2.144] (220-245-82-41.static.tpgi.com.au [220.245.82.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTP id D922D4B8072 for ; Thu, 13 Mar 2008 05:02:11 +1100 (EST) Message-ID: <47D81A9D.1010209@e164.org> Date: Thu, 13 Mar 2008 05:02:05 +1100 From: Duane User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "enum@ietf.org" References: <47D7F505.4080808@enum.at> In-Reply-To: <47D7F505.4080808@enum.at> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] comment on draft-ietf-enum-calendar-service-04 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Alexander Mayrhofer wrote: > An alternative would be to define seperate subtypes for iMIP and CalDAV > scheduling protocols, so that a client which does not support CalDAV > does not "run" into a URI scheme that it cannot use. there is sub-types to distinguish other url types and even duplicates of some url types as sub-url types...... > Actually this might even be a use case for those nasty "sub-sub-Types" > ("ical:sched:imip" and "ical:sched:caldav", but i'm pretty sure we don't > want to go down this road, do we? So things aren't messy enough for you, that you want to go and make a new one? :) -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Mar 13 13:55:39 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE93E28C2CB; Thu, 13 Mar 2008 13:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.887 X-Spam-Level: X-Spam-Status: No, score=-99.887 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_32=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0oh3UTZhGjH; Thu, 13 Mar 2008 13:55:38 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF023A6981; Thu, 13 Mar 2008 13:55:38 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2AE93A6803; Thu, 13 Mar 2008 13:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftN84b7ZyX8h; Thu, 13 Mar 2008 13:55:36 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id 7EDD73A6981; Thu, 13 Mar 2008 13:55:36 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JZuQP-0006wL-00; Thu, 13 Mar 2008 21:53:17 +0100 Date: Thu, 13 Mar 2008 21:53:17 +0100 From: Otmar Lendl To: enum@ietf.org, speermint@ietf.org Message-ID: <20080313205316.GA26506@nic.at> Mail-Followup-To: Otmar Lendl , enum@ietf.org, speermint@ietf.org Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: [Enum] Regarding enum-source-uri-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org During the ENUM session today it was mentioned that there is a requirement from speermint regarding this. I disagree. The requirement concerns the selection of ingress elements depending on the source SIP operator. That does not ipso facto mean that this has to happen in an ENUM lookup. In speermint parlance, there are the LUF (who owns a number) and the LRF (how to I route to the destination) query steps. For the LUF, the obvious protocol candidate is ENUM. We do NOT need the source variability there. Who owns a number does not depend on who is asking. It's a straight forward directory lookup. The LRF doesn't have a E.164 number as input. Some sort of "who owns this number" is the input. ENUM thus CANNOT be the protocol for this lookup. This is the query where the routing decision should be made, and that decision will be potentially influenced by a lot more information than just the destination and the source URI. Speermint hasn't decided on any protocol for the LRF. It's only if you combine those two lookups into a single query, that this requirement ends up applying to ENUM. Merging these queries kills URI-based routing. (How do you do the source variability with ENUM if the user wants to IM to a SIP URI?) I strongly advise against this. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 17 11:40:34 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244363A6E7E; Mon, 17 Mar 2008 11:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.549 X-Spam-Level: X-Spam-Status: No, score=-100.549 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3f1mEsA+huh; Mon, 17 Mar 2008 11:40:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80BCF3A6E02; Mon, 17 Mar 2008 11:40:32 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471FA3A6E02 for ; Mon, 17 Mar 2008 11:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bx4vptPr4AGu for ; Mon, 17 Mar 2008 11:40:29 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 60A493A6D6F for ; Mon, 17 Mar 2008 11:40:29 -0700 (PDT) Received: from rshockeyPC (h-68-165-240-38.mclnva23.covad.net [68.165.240.38]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m2HIatD5014934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 17 Mar 2008 10:36:57 -0800 From: "Richard Shockey" To: Date: Mon, 17 Mar 2008 14:37:17 -0400 Message-ID: <006101c8885d$eed60a80$cc821f80$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciIXe1qF+EvwhqVRpqG3j/EwzOYYQ== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [Enum] preliminary notes from the WG meeting in Philidelphia .. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Actually thanks to Jason for taking the notes here ... If there is anyting we left out here let us know. IETF 71 ENUM WG Notes 03/13/2008 15:10 hrs 1 - Scott Bradner and Lawrence Conroy present 3761-bis update - Document looks done - WG chairs and authors have indicated that WGLC will be issued next week (week of 17 March) - one minor issue to correct in draft was the IANA considerations. 2 - Alex Mayrhofer presents update on all ENUM WG drafts in queue A - Unused draft discussion: - Some discussion of draft-ietf-enum-unused was declared as DEAD. - Hadriel Kaplan, and Rohan Mahy objected to this dropping solely because the editor has retired. - Lawrence Conroy mentioned several AD objections - Jon Peterson (AD) noted that many concerns have been raised on this I-D over time. He suggested Lawrence make a few changes, that he felt could enable the draft to progress. - Lawrence will FOLLOW UP and publish Jon's comments / suggestions on the WG list. One was related to the data URI, which Jon has STRONG objections to. Jon believes there are valid alternatives to the data URI, and he thinks with those changes it could progress - Hadriel Kaplan strongly objects top dropping the draft. - Rohan Mahy agrees that the use of data URI is inappropriate, but he believes there are alternatives, as this draft is important, and that we should find a new editor that could move this draft along. - Lawrence Conroy suggests that any new editor be young, as this could take forever. - Rich Shockey will go to the list and declare the draft 'abandoned' and ask the WG if anyone wishes to take over the draft as editor. - Hadriel Kaplan has volunteered to take over the draft, and the chairs accepted happily. - Jon Peterson read out the WG charter and feels that the milestones are a couple of years in the past, and he suggests that the chairs may wish to update their milestones. And 'please do tell me what we're doing here' so the WG needs to clarify the charter text as well. B - Infrastructure draft discussion: - Jon Peterson said he thinks that the draft will go to last call before IETF 72. It has been held up for an external review of the document, but he feels it is about to move ahead. C - EDNS0 draft discussion: - Alex said the draft is waiting for a new revision, and this was indicated to be imminent. D - CNAM draft discussion: - Alex said the draft is waiting for a new revision, and this was indicated to be imminent. E - IAX draft discussion: - Alex said draft is expired, and Ed Guy (editor) said it will be updated shortly, which will renew the draft. F - Calendar draft discussion: - Rohan Mahy indicated that Alex Mayrhofer contacted him to add some things to the draft. - Rohan got some new sub-type suggestions while in IESG review, in order to have one URI for accessing a calendar and one URI for scheduling a new calendar item. - Rohan will post the sub-types he is thinking of on the WG list, but no objections raised in the meeting room. G - Document Flowchart shown by Alex, which demonstrated the linkages between 3761bis, x-services, enumservices guide, experiences. - Jon Peterson said that the enumservices guide can move ahead independently of 3761bis and experiences. 3 - Alex Mayrhofer presents update on ENUMservice Guide - Many changes since IETF 70 - Is no longer a guide and template, now actually specifies the IANA registry, registration procedures, guidelines. - 3761 no longer contains the registry guide. - New registration process, which is easier and simpler than before. Based pn expert review, in combination with specification required. This is based on RFC2434bis process, plus flowchart for feedback collection. - All registration specs moved from 3761bis, such as IANA registry specification, and IANA registration template - Classifications are: Protocol, Application, Data Format. Class would be listed in the registration template, but it is okay to have a NULL class. - URI scheme and sub-type relations were explained a bit, as there are some changes here. - Alex asked the WG whether 'Intended Usage' is really of use to the registration. - Jon Peterson felt that drafts like the PSTN draft might be designated as LIMITED USE, so he feels that we may want to look back through the registray and pick registrations out that are limited use and designate them as such. This is also an arguement for keeping this Intended Usage field. - Alex also indicated that the 'Name' field is not really used or defined. 3 options: (1) leave it unspecified, which is preferred by Alex, (2) specify further, or (3) remove it from the registration template. - Jon Peterson says: either specify what this is, or remove it. - Jon Peterson asked the room if anyone felt it was needed, and no one spoke up. Thus, he recommended its removal. But he asked that we evaluate the existing registry and determine what would have to be removed from previous registrations. - Alex also raised the issue of how to publish the registration documents themselves. - Jon Peterson suggested that it should be either a RFC or a published, stable public document. - Peter Koch suggested that other standards bodies could publish such documents. He suggested 'specification required.' - Scott Bradner suggested that if it was not a RFC, that the reference to the document should include a reference to a specific revision. - Lawrence Conroy suggested that within IETF this would mean it would need to be a RFC, and Scott Bradner agreed with this statement. - Some discussion between Alex, Scott Bradner, and Rich Shockey: Once the registration document has been completed and RFC published that expert review can obsolete previous or other registrations, and this needs to be specified in the new revision of the draft. ((IS THIS CORRECT??)) - Alex closed by mentioning that there is an online issue tracker for this document. 4 - Rich Shockey discussed the potential use of a 'p flag' with the group and asked if it was a good idea. - Jack Burton asked if you queried - Bob Moscowitz said he runs extensive ENUM zones internally, which have some views of external data, and he does not think it is needed. - Lawrence Conroy said this is basically 'leakage control' and he said that if you are on the global internet and you get a record with a p-flag, it indicates a leakage and it should be ignored. - Rich said he'll take this issue to the WG mailing list. - Peter Koch suggested that the text would need to be reworded, but the intent seems good. He will also help write this text with Rich Shockey and Lawrence Conroy. - Jon Peterson asked if this would hold up the enumservices guide until this question is resolved. - Lawrence Conroy things it would not hold up the guide, that text would need to go into 3761bis. - Jon Peterson would like to see a concrete proposal before he says if this is crazy or not. - Patrik Falstrom indicated that there should be use and mis-use cases (failure or leakage cases) described clearly. - Tom Creighton raised a question that the normative language is not specified on this proposal, and should be described when this is proposed more formally on the list. 5 - Presentation by Olafur Gudmundsson, DNSext WG Chairman - EDNS0 specs are being revised now, target is to move to draft standard. - That WG is discussing whether ENDS0 support should be mandated, and whether the minimum buffer size should be specified. Please get onto the DNSext WG list and discuss if you have an opinion. 6 - Presentation by Hadriel Kaplan regarding Private ENUM real-world use. - He is suggesting a problem statement that these mechanisms are missing source-based queries. - This is not a public ENUM issue, but a private one. - Proposed solution is to use EDNS0 to define a OPT-RR. - The mailing list has suggested other things like LDAP, SQL, and other mechanisms. But Hadriel said there are big reasons why this is not the case, such as the speed of DNS, efficiency, low cost, easy distribution of data, etc. - One speaker (??) suggested that he supported this draft. - Lawrence Conroy questioned what WG this should be in, and that ENUM WG may not be appropriate. He suggested DNSops or DNSext as potential options, since the applications could be more broad that ENUM. - Jean-Francois Mule said that he felt high-level requirements are needed in this draft. He does not understand the problem or the solution. - Peter Koch expressed a strong opinion that this work should be in a different WG, not in ENUM. He felt DNSext was the right WG. - Scott Bradner said that there is a party, Verizon, that has a related patent, and we should be careful. - Tim Dewhite from Verizon said that he felt this was useful to do local vs. toll lookups. - Co-Chairs cut-off discussion for time reasons. Rich indicated that another revision is necessary and there will be more discussion on the list. - Jon Peterson agreed with Jean-Francois Mule that there needs to be a better description of the problem and the solution. - Patrick Falstrom also suggested that Hadriel work closely with the DNSext folks for their input. /////////////////// OFFICIAL AGENDA BELOW /////////////////// IETF 71 Telephone Number Mapping (ENUM) WG Agenda THURSDAY, March 13, 2008 1510-1610 Afternoon Session II Franklin 3/4 INT savi Source Address Validation Improvements BOF Franklin 11/12 RAI avt Audio/Video Transport WG Franklin 6/7 RAI enum Telephone Number Mapping WG Salon I SEC smime S/MIME Mail Security WG Chair(s): Patrik Faltstrom Richard Shockey WG Secretary: Alexander Mayrhofer RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com RAI Area Advisor: Jon Peterson jon.peterson@neustar.biz Agenda Bashing. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Mar 18 03:47:27 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C2E28C528; Tue, 18 Mar 2008 03:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPqV9V30mLiT; Tue, 18 Mar 2008 03:47:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D9373A6D9D; Tue, 18 Mar 2008 03:47:26 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA833A6B9B for ; Tue, 18 Mar 2008 03:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45vnG+pdpf-Y for ; Tue, 18 Mar 2008 03:47:24 -0700 (PDT) Received: from anchor-internal-1.mail.demon.net (anchor-internal-1.mail.demon.net [195.173.56.100]) by core3.amsl.com (Postfix) with ESMTP id 9191A28C2F8 for ; Tue, 18 Mar 2008 03:47:23 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id m2IAj6xE014810Tue, 18 Mar 2008 10:45:06 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1JbZJW-000AzS-00; Tue, 18 Mar 2008 10:45:02 +0000 Date: Tue, 18 Mar 2008 10:45:02 +0000 From: "Clive D.W. Feather" To: Richard Shockey Message-ID: <20080318104502.GI30393@finch-staff-1.thus.net> References: <006101c8885d$eed60a80$cc821f80$@us> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <006101c8885d$eed60a80$cc821f80$@us> User-Agent: Mutt/1.5.3i Cc: enum@ietf.org Subject: Re: [Enum] preliminary notes from the WG meeting in Philidelphia .. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard Shockey said: > A - Unused draft discussion: [...] > - Lawrence will FOLLOW UP and publish Jon's comments / suggestions on the WG > list. One was related to the data URI, which Jon has STRONG objections to. > Jon believes there are valid alternatives to the data URI, and he thinks > with those changes it could progress > - Rohan Mahy agrees that the use of data URI is inappropriate, Are these objections to the data URI documented anywhere? As far as I can see, it's the right thing to use for a whole slew of stuff including this. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Mar 18 08:53:29 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3DC528C5F0; Tue, 18 Mar 2008 08:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.228 X-Spam-Level: X-Spam-Status: No, score=-101.228 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT5sJEDxDRJb; Tue, 18 Mar 2008 08:53:25 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D008628C4D8; Tue, 18 Mar 2008 08:53:25 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE6228C44F for ; Tue, 18 Mar 2008 08:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40SRUlFkbBuI for ; Tue, 18 Mar 2008 08:53:19 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id CF82428C4D8 for ; Tue, 18 Mar 2008 08:53:19 -0700 (PDT) Received: from rshockeyPC (streamline120.sjccnet.com [207.87.51.120]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m2IFlade028785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2008 07:48:00 -0800 From: "Richard Shockey" To: "'Clive D.W. Feather'" References: <006101c8885d$eed60a80$cc821f80$@us> <20080318104502.GI30393@finch-staff-1.thus.net> In-Reply-To: <20080318104502.GI30393@finch-staff-1.thus.net> Date: Tue, 18 Mar 2008 11:48:20 -0400 Message-ID: <1a0601c8890f$8facf250$af06d6f0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciI5QkAA8RBNFnaTg2tApLFUwX3EwAKj9xg Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: enum@ietf.org Subject: Re: [Enum] preliminary notes from the WG meeting in Philidelphia .. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I had the same problem with the CNAM draft ..the word from on high is that they don't want us to use data: but specific URI's. We are just doing what we are told. IMHO its similar to the issues with TXT in RR ..its just become a junk pile for anyone trying to do anything. > -----Original Message----- > From: Clive D.W. Feather [mailto:clive@demon.net] > Sent: Tuesday, March 18, 2008 6:45 AM > To: Richard Shockey > Cc: enum@ietf.org > Subject: Re: [Enum] preliminary notes from the WG meeting in > Philidelphia .. > > Richard Shockey said: > > A - Unused draft discussion: > [...] > > - Lawrence will FOLLOW UP and publish Jon's comments / suggestions > on the WG > > list. One was related to the data URI, which Jon has STRONG > objections to. > > Jon believes there are valid alternatives to the data URI, and he > thinks > > with those changes it could progress > > > - Rohan Mahy agrees that the use of data URI is inappropriate, > > Are these objections to the data URI documented anywhere? As far as I > can > see, it's the right thing to use for a whole slew of stuff including > this. > > -- > Clive D.W. Feather | Work: | Tel: +44 20 8495 > 6138 > Internet Expert | Home: | Fax: +44 870 051 > 9937 > Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 > 377646 > THUS plc | | _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Mar 18 09:46:43 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC55C3A6D90; Tue, 18 Mar 2008 09:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.378 X-Spam-Level: X-Spam-Status: No, score=-101.378 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_55=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqo4RO6eTguX; Tue, 18 Mar 2008 09:46:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 075993A6F12; Tue, 18 Mar 2008 09:46:07 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C73573A6EF9 for ; Tue, 18 Mar 2008 09:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNpdAyCjj-Ax for ; Tue, 18 Mar 2008 09:46:04 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 4AFA328C676 for ; Tue, 18 Mar 2008 09:45:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,519,1199664000"; d="scan'208";a="16159884" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 18 Mar 2008 16:43:37 +0000 In-Reply-To: <1a0601c8890f$8facf250$af06d6f0$@us> To: "Richard Shockey" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 18 Mar 2008 16:43:36 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 18/03/2008 04:43:37 PM, Serialize complete at 18/03/2008 04:43:37 PM Cc: enum@ietf.org, "'Clive D.W. Feather'" Subject: Re: [Enum] preliminary notes from the WG meeting in Philidelphia .. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > I had the same problem with the CNAM draft ..the word from on high is that > they don't want us to use data: but specific URI's. We are just doing what > we are told. IMHO its similar to the issues with TXT in RR ..its just become > a junk pile for anyone trying to do anything. I have a potential draft to be co-authored with Clive to formally document an ENUM (sub-)service-type and NAPTR record that is to be used in the UK's number portability database. It's currently represented as a (very) short data: URI, containing either one or two short numbers, i.e. data:,1 or data:,8-10. The information therein is meta-information about the ENUM tree. Like Clive, I agree that the data: URI format is perfect for this. I've looked at the currently registered URI schemes and there's nothing else suitable. A previous version of the specification held the information in a TXT record but this was discarded in favour of NAPTR records to ensure that a single DNS query with QTYPE=NAPTR could return both meta-data and real data. Jon - are we supposed to invent a new URI scheme to represent this? FWIW - there are UK Neustar people involved with this particular project too. cheers, Ray -- Ray Bellis, MA(Oxon) Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Mar 18 11:18:31 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 860563A6F46; Tue, 18 Mar 2008 11:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.228 X-Spam-Level: X-Spam-Status: No, score=-101.228 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uv4sMlnPY7WF; Tue, 18 Mar 2008 11:18:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4754328C656; Tue, 18 Mar 2008 11:18:23 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F7BC3A6F36 for ; Tue, 18 Mar 2008 11:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVgPd5jOX-e1 for ; Tue, 18 Mar 2008 11:18:16 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id BF89128C6B1 for ; Tue, 18 Mar 2008 11:17:53 -0700 (PDT) Received: from rshockeyPC (sjcc86x81.sjccnet.com [207.86.63.81]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m2IIETTE007033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Mar 2008 10:14:38 -0800 From: "Richard Shockey" To: Date: Tue, 18 Mar 2008 14:15:14 -0400 Message-ID: <007e01c88924$09e723b0$1db56b10$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciIn40wLpANRiqeRlyS8BSzbo/jJgAhG2fg Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [Enum] FW: I-D Action:draft-ietf-dnsext-rfc2671bis-edns0-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, March 17, 2008 10:30 PM To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D Action:draft-ietf-dnsext-rfc2671bis-edns0-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Revised extension mechanisms for DNS (EDNS0) Author(s) : P. Vixie Filename : draft-ietf-dnsext-rfc2671bis-edns0-01.txt Pages : 9 Date : 2008-03-17 The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow.1 - Introduction A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-01.tx t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Mar 18 11:32:09 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07DF028C685; Tue, 18 Mar 2008 11:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.557 X-Spam-Level: X-Spam-Status: No, score=-100.557 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuhtqZlBATwQ; Tue, 18 Mar 2008 11:32:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5F528C637; Tue, 18 Mar 2008 11:32:07 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47AA23A6849 for ; Tue, 18 Mar 2008 11:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xvLmTbjP2Vk for ; Tue, 18 Mar 2008 11:32:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B95AC3A6A21 for ; Tue, 18 Mar 2008 11:32:05 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 18 Mar 2008 14:29:27 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 18 Mar 2008 14:29:27 -0400 From: Hadriel Kaplan To: Richard Shockey , "enum@ietf.org" Date: Tue, 18 Mar 2008 14:28:31 -0400 Thread-Topic: [Enum] preliminary notes from the WG meeting in Philidelphia .. Thread-Index: AciIXe1qF+EvwhqVRpqG3j/EwzOYYQAx0/Iw Message-ID: References: <006101c8885d$eed60a80$cc821f80$@us> In-Reply-To: <006101c8885d$eed60a80$cc821f80$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Enum] preliminary notes from the WG meeting in Philidelphia .. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Howdy, Inline... > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Richard Shockey > > 6 - Presentation by Hadriel Kaplan regarding Private ENUM real-world use. > - He is suggesting a problem statement that these mechanisms are missing > source-based queries. > - This is not a public ENUM issue, but a private one. > - Proposed solution is to use EDNS0 to define a OPT-RR. > - The mailing list has suggested other things like LDAP, SQL, and other > mechanisms. But Hadriel said there are big reasons why this is not the > case, such as the speed of DNS, efficiency, low cost, easy distribution of > data, etc. > - One speaker (??) suggested that he supported this draft. > - Lawrence Conroy questioned what WG this should be in, and that ENUM WG > may > not be appropriate. He suggested DNSops or DNSext as potential options, > since the applications could be more broad that ENUM. > - Jean-Francois Mule said that he felt high-level requirements are needed > in > this draft. He does not understand the problem or the solution. That was not my recollection of his comments. I remember him saying that he saw a need for this, based on Speermint. > - Peter Koch expressed a strong opinion that this work should be in a > different WG, not in ENUM. He felt DNSext was the right WG. > - Scott Bradner said that there is a party, Verizon, that has a related > patent, and we should be careful. > - Tim Dewhite from Verizon said that he felt this was useful to do local > vs. > toll lookups. > - Co-Chairs cut-off discussion for time reasons. Rich indicated that > another revision is necessary and there will be more discussion on the > list. > - Jon Peterson agreed with Jean-Francois Mule that there needs to be a > better description of the problem and the solution. > - Patrick Falstrom also suggested that Hadriel work closely with the > DNSext > folks for their input. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Mar 18 18:45:35 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A253A6E34; Tue, 18 Mar 2008 18:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.503 X-Spam-Level: X-Spam-Status: No, score=-100.503 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_55=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvHw4GEwQLdf; Tue, 18 Mar 2008 18:45:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 234443A6E01; Tue, 18 Mar 2008 18:45:34 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4DE13A6D99 for ; Tue, 18 Mar 2008 18:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLkxfFibrljd for ; Tue, 18 Mar 2008 18:45:31 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 60BBB3A6E03 for ; Tue, 18 Mar 2008 18:45:31 -0700 (PDT) Received: from rshockeyPC (streamline120.sjccnet.com [207.87.51.120]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m2J1g8NO030370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2008 17:42:11 -0800 From: "Richard Shockey" To: References: <1a0601c8890f$8facf250$af06d6f0$@us> In-Reply-To: Date: Tue, 18 Mar 2008 21:42:53 -0400 Message-ID: <025501c88962$8ea7c8a0$abf759e0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciJFzxc/IX0p+EcTkW4sMg7SEgo8AASm4jA Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: enum@ietf.org, "'Clive D.W. Feather'" Subject: Re: [Enum] preliminary notes from the WG meeting in Philidelphia .. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org In line ... as I mentioned before I had the same problem of using the DATA: uri scheme in my CNAM drafts. You do not want to know the time and effort I went through to understand that the use of DATA: would not happen. The only solution is another URI type which, for lack of anything better, we are going to call PSTNDATA: I have already socialized the general scheme with the powers that be and there seems to be no general objection to a new URI type for the specific purpose of general pstn data types in conjunction with the correct ENUM service registration etc. This IMHO is the way to go forward on these issues. My personal advice would be to revise your drafts accordingly. > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Ray.Bellis@nominet.org.uk > Sent: Tuesday, March 18, 2008 12:44 PM > To: Richard Shockey > Cc: enum@ietf.org; 'Clive D.W. Feather' > Subject: Re: [Enum] preliminary notes from the WG meeting in > Philidelphia .. > > > I had the same problem with the CNAM draft ..the word from on high > is > that > > they don't want us to use data: but specific URI's. We are just > doing > what > > we are told. IMHO its similar to the issues with TXT in RR ..its > just > become > > a junk pile for anyone trying to do anything. > > I have a potential draft to be co-authored with Clive to formally > document > an ENUM (sub-)service-type and NAPTR record that is to be used in the > UK's > number portability database. > > It's currently represented as a (very) short data: URI, containing > either > one or two short numbers, i.e. data:,1 or data:,8-10. The information > therein is meta-information about the ENUM tree. > > Like Clive, I agree that the data: URI format is perfect for this. > I've > looked at the currently registered URI schemes and there's nothing > else > suitable. A previous version of the specification held the > information in > a TXT record but this was discarded in favour of NAPTR records to > ensure > that a single DNS query with QTYPE=NAPTR could return both meta-data > and > real data. > > Jon - are we supposed to invent a new URI scheme to represent this? > FWIW > - there are UK Neustar people involved with this particular project > too. > > cheers, > > Ray > > -- > Ray Bellis, MA(Oxon) > Senior Researcher in Advanced Projects, Nominet > e: ray@nominet.org.uk, t: +44 1865 332211 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Mar 18 19:29:13 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56B728C291; Tue, 18 Mar 2008 19:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.567 X-Spam-Level: X-Spam-Status: No, score=-100.567 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPCvyNZ+SnCj; Tue, 18 Mar 2008 19:29:12 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB583A6857; Tue, 18 Mar 2008 19:29:12 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B40F3A6857 for ; Tue, 18 Mar 2008 19:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOR14oQtRRSj for ; Tue, 18 Mar 2008 19:29:10 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 00B403A6851 for ; Tue, 18 Mar 2008 19:29:09 -0700 (PDT) Received: from rshockeyPC (streamline120.sjccnet.com [207.87.51.120]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m2J2PR42024932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2008 18:25:45 -0800 From: "Richard Shockey" To: References: <1a0601c8890f$8facf250$af06d6f0$@us> In-Reply-To: Date: Tue, 18 Mar 2008 22:26:10 -0400 Message-ID: <0bdf01c88968$a683f8d0$f38bea70$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciJFxzF2X0yk3MeSSWiT3y2k7ShkgAUUD4A Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: enum@ietf.org, "'Clive D.W. Feather'" Subject: Re: [Enum] preliminary notes from the WG meeting in Philidelphia .. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org FYI ..this is what I have so far ..you can obviously suggest another data type. Comments are welcome ********************** IANA Registration Template for URI "pstndata:" URI scheme name. The name of the URI is "pstndata:". Status. The intended status is Permanent. NOTE: The distribution of CNAM data is often highly restricted. Usage of this URI should either be within a service providers internal network, or on a private basis between one or more parties using a variety of security mechanisms to prevent general public access. The records described herein should not be part of the e164.arpa or any other portion of the DNS tree. URI scheme syntax. pstndatauri = "pstndata:" datatype ["/" telephone-subscriber ] ";" (content / reason) datatype = "cnam" ; Other datatypes can be defined by adding alternative values. content = [ mediatype ] [ ":base64" ] "," data mediatype = [ type "/" subtype ] *( ";" parameter ) data = *urlchar parameter = attribute "=" value reason = "available=" ("p" / "u") where "telephone-subscriber" is imported from RFC 3966 [19], "urlchar" is imported from RFC 2396 [20], and "attribute" and "value" are imported from RFC 2045 [21]. URI scheme semantics. Two optional parameters are defined. a) Calling Name Privacy Indicator: 'available=p' This parameter defined as the Calling Name information may be available but the Calling Party does not wish to have their Calling Name data displayed by Called Party User Agents. Intended usage: 'available=p' b) Calling Name Status Indicator: 'available=u' This parameter is defined as there is no Calling Name data for that E.164 number available. Intended usage: 'unavailable=u' Encoding considerations. The purpose of this URI is to enable service providers to place Calling Name Delivery information (CNAM) into RFC 3761 [ENUM] databases or to send ENUM queries to a protocol converter that would have access to the Signaling System 7 (SS7) Network. This, in turn, could enable such parties to offer Calling Name Delivery services using the technology provided by RFC 3761. The information stored in these databases can be encoded to facilitate storage and retrieval operations. The type of encoding used is identified using appropriate media type parameters. If not otherwise identified, character data is presumed to be encoded using US-ASCII [9]. Applications and/or protocols that use this URI scheme name. This URI scheme is intended for use in RFC 3761 [ENUM] databases. Interoperability considerations. The URI is designed to be used specifically in conjunction with trusted systems that utilize the RFC 3761 [ENUM] databases. Security considerations: The distribution of CNAM data is often highly restricted. Distribution of this data would typically be either within a service providers internal network, or on a private basis between one or more parties using a variety of security mechanisms to prohibit general public access. It should be noted that this content type is designed to carry potentially personal information and as such, may be subject to restrictions within various national jurisdictions. . In many cases, the actual information that needs to be protected is the combination of the Name associated with the Telephone Number or the association of the name with the telephone call. So, it will be necessary to protect the response to the query that provides the association between the two elements. The pstn URI defined in this document is assumed to be used in an environment where elements are trusted and where attackers are not supposed to have access to the protocol messages between those elements. Traffic protection between network elements is sometimes achieved by using IPSec [A] and sometimes by physically protecting the underlying network. In any case, the provider should ensure that measures are taken to prevent both fraud and unauthorized disclosure by using a combination of authentication and Encryption. > > Jon - are we supposed to invent a new URI scheme to represent this? > FWIW > - there are UK Neustar people involved with this particular project > too. > > cheers, > > Ray > > -- > Ray Bellis, MA(Oxon) > Senior Researcher in Advanced Projects, Nominet > e: ray@nominet.org.uk, t: +44 1865 332211 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Mar 19 02:14:12 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8A0828C223; Wed, 19 Mar 2008 02:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.769 X-Spam-Level: X-Spam-Status: No, score=-100.769 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDwHEz1zCSQ9; Wed, 19 Mar 2008 02:14:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1990E3A6AAD; Wed, 19 Mar 2008 02:14:04 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087EB28C0D6 for ; Wed, 19 Mar 2008 02:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+1kEBdBnHzZ for ; Wed, 19 Mar 2008 02:13:51 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 20A623A6A92 for ; Wed, 19 Mar 2008 02:13:24 -0700 (PDT) Received: from [10.10.0.112] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTP id 677344C670; Wed, 19 Mar 2008 10:11:04 +0100 (CET) Message-ID: <47E0D8A6.9050303@nic.at> Date: Wed, 19 Mar 2008 10:11:02 +0100 From: Otmar Lendl User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hadriel Kaplan References: <006101c8885d$eed60a80$cc821f80$@us> In-Reply-To: Cc: "enum@ietf.org" , Richard Shockey Subject: Re: [Enum] preliminary notes from the WG meeting in Philidelphia .. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hadriel Kaplan wrote: >> - Jean-Francois Mule said that he felt high-level requirements are needed >> in this draft. He does not understand the problem or the solution. > > That was not my recollection of his comments. I remember him saying that he saw a need for this, based on Speermint. IMHO this derives from http://tools.ietf.org/html/draft-ietf-speermint-requirements-04 o Requirement #4: The mechanisms recommended for the declaration or advertisement of SBE and DBE entities must allow for peer and media variability. /ol _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Mar 29 07:15:07 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7C528C3D0; Sat, 29 Mar 2008 07:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R02wExam1AFN; Sat, 29 Mar 2008 07:15:06 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 182A028C1B2; Sat, 29 Mar 2008 07:15:05 -0700 (PDT) X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3A8E73A6B9A; Sat, 29 Mar 2008 07:15:02 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080329141502.3A8E73A6B9A@core3.amsl.com> Date: Sat, 29 Mar 2008 07:15:02 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] I-D Action:draft-ietf-enum-unused-04.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org 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 Enumservice UNUSED Author(s) : R. Stastny, et al. Filename : draft-ietf-enum-unused-04.txt Pages : 16 Date : 2008-03-29 This document registers the Enumservice "unused" using the URI scheme "http:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-unused-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-enum-unused-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-03-29071314.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Sat Mar 29 07:57:07 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B761B3A6C95; Sat, 29 Mar 2008 07:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.917 X-Spam-Level: X-Spam-Status: No, score=-95.917 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_66=0.6, MPART_ALT_DIFF_COUNT=1.11, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJJW3d+vJAHH; Sat, 29 Mar 2008 07:57:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE963A6B0C; Sat, 29 Mar 2008 07:57:04 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F13A3A6CA2 for ; Sat, 29 Mar 2008 07:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWDfuS4Pkzey for ; Sat, 29 Mar 2008 07:56:59 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 91E8A3A6C95 for ; Sat, 29 Mar 2008 07:56:56 -0700 (PDT) Received: from [127.0.0.1] (norman.insensate.co.uk [213.152.49.123]) by insensate.co.uk (Postfix) with ESMTP id DD2E189441 for ; Sat, 29 Mar 2008 14:56:50 +0000 (GMT) Message-Id: From: Lawrence Conroy To: enum@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 29 Mar 2008 14:56:50 +0000 X-Mailer: Apple Mail (2.919.2) Subject: [Enum] Unused - dead cat bounce X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1427801876==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1427801876== Content-Type: multipart/alternative; boundary=Apple-Mail-11-862144102 --Apple-Mail-11-862144102 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Folks, As agreed in PHL, I enclose Jon's review comments on draft-ietf-enum- unused-03. I also enclose a hitherto unpublished unused-04.xml (made in response to comments in YVR). This replaces the -03 version, and uses an http: URI rather than a data: URI. The http: URL could contain a link to the block owner's web site, or the NRA's web site, or other link if required and permitted by the competent NRA, or appropriate definitions of the terms unused and unassigned, or ... If anyone wants the XML source for the -03 version, send me a mail. all the best, Lawrence --Apple-Mail-11-862144102 Content-Type: multipart/mixed; boundary=Apple-Mail-12-862144102 --Apple-Mail-12-862144102 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Hi Folks,

As agreed in PHL, I enclose Jon's review comments on draft-ietf-enum-unused-03.

I also enclose a hitherto unpublished unused-04.xml (made in response to comments in YVR).

This replaces the -03 version, and uses an http: URI rather than a data: URI.
The http: URL could contain a link to the block owner's web site, or the NRA's web site, or other link if required and permitted by the competent NRA, or appropriate definitions of the terms unused and unassigned, or ...

If anyone wants the XML source for the -03 version, send me a mail.

all the best,
  Lawrence
--Apple-Mail-12-862144102 Content-Disposition: attachment; filename=AD-review-of-draft-ietf-enum-unused.txt Content-Type: text/plain; x-unix-mode=0664; x-mac-type=54455854; name="AD-review-of-draft-ietf-enum-unused.txt" Content-Transfer-Encoding: 7bit From: "Peterson, Jon" Date: 7 January 2008 23:27:07 GMT To: Cc: , Subject: AD review of draft-ietf-enum-unused Before I paste in my review here, just for the sake of Richard and Jim, Lawrence and I discussed this at some length in Vancouver. As I said then, I would really prefer that enum-unused not make use of the "data" URL scheme. Lawrence suggested that it might be possible to return to an HTTP URL instead. I also repeatedly entreated Lawrence to consider trying to flip this problem around (as the last sentence of my review below suggests) or otherwise try to turn this from a problem the DNS does not know how to solve into one that the DNS can solve easily. Ultimately, that may not be possible. Lawrence did ask to see my detailed review notes before further considering this, so, here they are. I understand that a lot of work has gone into this proposal over the years, but I remain skeptical of the underlying requirements, the general architectural direction, and the specific technical solution. The requirements text of 3.4 notes, quite rightly, that in cases 1 and 2, if the call is attempted on the PSTN, and error message will occur. It is also true that a resolver cannot distinguish between cases 4 and 5, and thus the application will not be able to tell whether or not attempting the call on the PSTN would succeed. But my question is this: what is the problem, exactly? A call on the PSTN can fail for a number of reasons that have nothing to do with whether or not a number is allocated - do we need to be able to anticipate all of those conditions too, before we place a call? Of course I agree that in an ideal world, terminals would be able to anticipate that a call would fail before it is placed if the condition is predictable. But I'm not sure it is ENUM's responsibility to know whether or not a call that is placed outside the Internet will succeed. I am also a bit skeptical that the looping behavior described in 3.5 would be instantiated in a reasonable deployment network. Even the most trivial gateways can be provisioned to distinguish number ranges which are considered "local" or "on-net" from those that are reachable through the PSTN. Just because a number cannot be reached over the Internet does not mean that it must be dropped to the PSTN; stipulating that a gateway's routing decision must be based solely on what it learns from ENUM speaks to a gateway implementation problem, not a problem that necessarily needs to be rectified by defining new enumservices. Architecturally, as was the case with previous incarnations of this proposal, this mechanism seems to introduce a DNS response code in the form of an enumservice. The argument of 3.2 and 3.3 is basically "this is why the current RCODEs are not sufficient." The new response code appears as an enumservice because ENUM is where the perceived need for this RCODE has emerged. The idea that a DNS label is "unused" per cases 1, 2 and 6 in Section 3.1 is something for which no RCODE currently exists, though hypothetically one could imagine an RCODE that serves this purpose rather than an enumservice. I am not sure it is within the scope of the ENUM working group to provide new RCODEs or protocol elements that effectively serve the purpose of RCODEs. Certainly this is not something I would feel comfortable doing without substantial review and approval from the DNS community. Since enumservices need to be associated with a regexp or replacement, the "unused" enumservice nominally contains a replacement to a data URI. I really don't feel that the data URI is an architecturally meaningful "replacement" for a telephone number - there is no sense in which transforming a telephone number into a data URI string identifies a resource. The examples in the draft (which include textual strings for "unassigned" and "unallocated") are unabashedly kludgey, and the syntax of the field is left open ("a national matter"). Suffice it to say that all this suggests to me that you don't really need a NAPTR record. There is no Naming Authority pointing going on in this record, even if the data URI seems to warp NAPTRs to the point where they don't signify anything more specific than a TXT record. I feel pretty strongly that populating DNS labels with NAPTR records containing the "unused" service is an undesirable solution to this problem. I wonder, though, if the problem is cast in a way that makes it prohibitively difficult to solve. Did you ever consider flipping this around by applying a flag to particular delegations or labels which would indicate that they are "ENUM-only"? - J --Apple-Mail-12-862144102 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
--Apple-Mail-12-862144102 Content-Disposition: attachment; filename=draft-ietf-enum-unused-04.xml Content-Type: text/xml; x-mac-creator=21526368; x-unix-mode=0664; x-mac-type=54455854; name="draft-ietf-enum-unused-04.xml" Content-Transfer-Encoding: 7bit IANA Registration for Enumservice UNUSED Oefeg
Postbox 147 1103 Vienna Austria +43-664-420-4100 Richard.stastny@oefeg.at
Siemens Roke Manor Research
Roke Manor Romsey United Kingdom +44-1794-833666 lwc@roke.co.uk
DNS-MODA
6 Langside Court Bothwell SCOTLAND United Kingdom +44 1698 852881 jim@dns-moda.org
Applications ENUM Internet-Draft DNS NAPTR ENUMSERVICE UNUSED E.164 This document registers the Enumservice "unused" using the URI scheme "http:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early".
The Circuit Switched Network (CSN) of which the Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN), and Public Land Mobile Network (PLMN) are part is designed to use E.164 numbers as native global addresses. If a potential caller has an E.164 number, then to place a call using this address he or she needs a way to pass the request either directly or indirectly to systems "in" the CSN for them to forward. ENUM ("E.164 Number Mapping") has introduced a mechanism to find other contact addresses when given an E.164 number. Thus, if the caller (or an agent somewhere in the call path) has access to the global Domain Name System (DNS), they can use ENUM as described in RFC 3761 to find alternative contacts to the E.164 number and place the call using whatever system was indicated in those contacts. In its intended use, an ENUM query would return a set of NAPTR ("Naming Authority Pointer") resource records , and these would be processed to select the appropriate communications contact choices. Each communications contact is held in a URI ("Universal Resource Indicator") generated from the contents of a NAPTR. However, ENUM entries may not exist for a given E.164 number for two reasons. Either the assignee who is entitled to register an ENUM domain associated with the E.164 number they hold has chosen not to request this registration, or the number is not currently allocated or assigned for communications service. In either situation, the caller has no other information and so no alternative to placing the call via the system that uses E.164 numbers as global identifiers; at present, this is the CSN.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
This section describes the problems that arise where the ENUM system does not hold full information on all telephone numbers and clients display typical behaviour. The proposed solution to the problems described here is covered in and in the unused Enumservice registration in .
Traditionally, communications service is provided via a network that uses telephone numbers as global addresses. Examples of such networks are the PSTN, ISDN and PLMN. ENUM registrations are normally allowed only to customers who receive communications service via a telephone number. There may or may not be an ENUM registration when such service is provided. An ENUM registration is usually not permitted when no customer receives service via the corresponding telephone number. When considering ENUM registrations associated with telephone numbers, there are six scenarios: The number is not allocated to a service provider, the number is not currently used by that provider for communications service for a customer, the number is used to provide communications service to a customer and either that customer has not chosen to maintain an ENUM registration associated with that number, or the National Regulatory Authority (NRA) responsible for these numbers does not allow ENUM registrations, the number is used to provide communications service to a customer and that customer has an ENUM registration associated with that number. Communications service may alternatively be provided only by recourse to an ENUM lookup. Such numbers are known as "ENUM only" ranges. For these numbers there are two further possibilities: There is an ENUM registration and that number may be used for communications service, there is no ENUM registration and therefore the number is not used for communications service.
Assuming properly configured name servers and protocol conformant software, an ENUM query on a domain associated with a telephone number may elicit one of several outcomes based on the DNS response. In uses cases 1,2,3,and 6, the DNS response will indicate Name Error (RCODE=3, commonly known as NXDOMAIN, signifying that the domain name referenced in the query does not exist). In use cases 4 and 5, the DNS response will indicate No Error (RCODE=0). There are three possibilities here: There may be at least one usable NAPTR (meaning one in which the Enumservice is supported and the URI is resolved), in which case a communications attempt can be made. Even though the DNS response indicates no error, there may not be any usable NAPTRs in that response. This may happen because the domain owner has chosen not to populate the zone with NAPTR records. This response (RCODE=0, Number of Answers=0) is also known as NOHOST, meaning that the queried name exists but not for the record type that was requested. However, even if there are NAPTRs returned, none of the ones present may be usable. For example, the NAPTR RRSet may include only an "h323" Enumservice, whilst the client node is capable only of processing "sip" or "voice:tel" Enumservices. As it cannot know the case it has encountered, if the client receives a DNS response with no usable NAPTRs or one with RCODE=3, it must decide whether or not to attempt to place the call using other means.
Not every customer has an ENUM registration if provided service via a network that uses telephone numbers natively, and until this is the case, a reasonable strategy has been to attempt to place the call via such a network if it receives an ENUM response with RCODE=3. This is especially true if the National Regulatory Authority has chosen not to permit ENUM registrations at all for the telephone numbers under its control. This may also be the chosen strategy if the client receives a response with RCODE=0 (No Error), but with no usable NAPTRs.
In the case of an ENUM client getting a DNS response with RCODE=3, the semantics of that reply are ambiguous. Is this case 1,2,3, or 6? It is useful for the client to know if this is case 3, as in this case the "default" strategy will succeed. In cases 1 and 2, trying to place the call via a network that uses such numbers natively will result in that network returning an error. However, in case 6 even this cannot be guaranteed. Similarly, if the client finds no usable NAPTRs, is this case 4 or case 5? In the latter case the strategy will fail, whilst in the former case it will succeed.
However, for the "ENUM only" cases, there is a further problem. If the call is placed via a network that uses such numbers natively, it can be processed only via an ENUM lookup, and typically this will involve a gateway from that network performing the lookup and delivering the call onwards based on the response. If that gateway receives a response with RCODE=3 or one including no usable NAPTRs, then employing the "default" strategy (attempting the call via a network that uses these numbers natively) will cause a "loop". The call will be redirected to this network, where it will be routed to a gateway, this gateway will perform a lookup, will receive the same response, will attempt to place the call back to that network, and so on.
We propose an explicit indication of this "number unused" state (as described in points 1,2, and 6 in ). This uses a NAPTR in the zone associated with an unused telephone number, with an Enumservice called "unused" that should be taken as an assertion that the associated E.164 number is not assigned to a subscriber for communications service; it's an unused number. This NAPTR can also be used by a National Regulatory Authority (NRA) to indicate number blocks that it has reserved, and has not allocated to a service provider. It is a matter for individual countries whether or not they will support (or require) information giving the identity of the current "owner" of an E.164 number within their responsibility to be made available via IRIS/WHOIS. Thus it may not be possible to use these protocols to find out the entity responsible for a number or number range concerned, particularly where that number or range is not currently "in use". Since the registration and syntax of a terminal NAPTR for "E2U" Enumservices requires at least one URI scheme to be defined, we propose that the Enumservice "unused" will use an "http:" URI. The content referenced in this "http:" URI is a national matter. For example, it may be used to refer to a resource providing additional information about the reason for the existence of this record, and/or (where required by the competent regulatory authority) the identity of the entity responsible for this number.
Enumservice Name: "unused" Enumservice Type: "unused" Enumservice Subtypes: "data" URI Schemes: "http:" Functional Specification: The proposed solution in . Definition of expected action: When an ENUM lookup for a number explicitly returns the "unused" NAPTR, the response indicates to the client that the number is known to ENUM but there are no implicit communication end-points associated with it. The client can then signal an error to the application or end user instead of then trying and failing to terminate the call on the PSTN, which would have been the typical behaviour of an ENUM-aware VoIP/PSTN gateway if the ENUM lookup had returned a DNS response indicating NXDOMAIN or NOHOST. Thus, if a NAPTR with this Enumservice is received and processed, it indicates that there are no possible communication methods that can be used to reach the end point. The queried E.164 number is currently not allocated, or unassigned to a subscriber for communications service. The recipient SHOULD treat this response as if they had received a "number not in service" indication from a terminating network. Note that the generated URI is not a potential target for any current call. The content referred to in the "http:" URI MUST NOT be used in normal call processing but only if there is a non-call related reason. Security considerations: see . Intended usage: COMMON Authors Lawrence Conroy, Richard Stastny, Jim Reid (for authors contact details see Authors' Addresses section). Any other information that the author deems interesting: None
Unassigned number $ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa. 3.8.0 NAPTR 10 100 "u" "E2U+unused:http"     "!^.*$!http://www.nra.example/static/numbering/cupid.htm?cupid=001!" . This indicates that the controller of the number block +441632960 does not provide telephony service via the number +441632960083; it is not assigned to a subscriber. Unallocated number $ORIGIN 0.6.9.4.5.1.1.4.4.e164.arpa. * NAPTR 10 100 "u" "E2U+unused:http"     "!^.*$!http://www.nra.example/static/numbering/sabc.htm?SABC=1154!" This indicates that the number block +441154960 is not allocated by the NRA to any service provider and therefore no number in this block provides any communication service.
DNS does not make policy decisions about the records that it shares with an inquirer. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM record set must therefore be considered to be open to the public. An analysis of threats specific to the dependence of ENUM on the DNS, and the applicability of DNSSEC ("Domain Name Security") to these, is provided in .
This document requests registration of the "unused" Enumservice with the sub-type "unused:http" according to the guidelines and specifications in RFC 3761 and the definitions in this document. This Enumservice is intended for use with the "http:" URI scheme.
Thanks to Patrik Faltstrom, Michael Mealling and Peter Koch for their thorough feedback, and colleagues in ETSI TISPAN who helped to clarify the operational features during the development of . Thanks also to the members of the ENUM working group for their wide ranging discussions. These have helped to indicate where changes were needed in this document to help explain what is an intrinsically difficult subject. Finally, thanks to Alex Mayrhofer for his useful document review, picking up the remaining issues.
Key words for use in RFCs to Indicate Requirement Levels Harvard University
Holyoke Center, Room 813 1350 Massachusettes Avenue Cambridge MA 02138 US +1 617 495 3864 sob@harvard.edu
The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
The International Public Telecommunication Number Plan ITU-T
Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database
DOMAIN NAMES - CONCEPTS AND FACILITIES
Hypertext Transfer Protocol -- HTTP/1.1
Protocol Modifications for the DNS Security Extensions
Threat Analysis of the Domain Name System (DNS)
Minimum Requirements for Interoperability of ENUM Implementations ETSI
--Apple-Mail-12-862144102 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
--Apple-Mail-12-862144102-- --Apple-Mail-11-862144102-- --===============1427801876== 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://www.ietf.org/mailman/listinfo/enum --===============1427801876==-- From enum-bounces@ietf.org Sat Mar 29 08:02:18 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 578793A6EEA; Sat, 29 Mar 2008 08:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.603 X-Spam-Level: X-Spam-Status: No, score=-98.603 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_34=0.6, J_CHICKENPOX_66=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwNoz2FQ-q05; Sat, 29 Mar 2008 08:02:13 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9693A6EDC; Sat, 29 Mar 2008 08:02:13 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413CA3A6EE7 for ; Sat, 29 Mar 2008 08:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksMeWZc12QJ7 for ; Sat, 29 Mar 2008 08:01:57 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 86ECF3A6CF8 for ; Sat, 29 Mar 2008 08:01:35 -0700 (PDT) Received: from [127.0.0.1] (norman.insensate.co.uk [213.152.49.123]) by insensate.co.uk (Postfix) with ESMTP id 31A1389445 for ; Sat, 29 Mar 2008 15:01:34 +0000 (GMT) Message-Id: <5F51DF7B-2A8D-4C55-BD4A-52EC6F9AA9B5@insensate.co.uk> From: Lawrence Conroy To: enum@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-14-862427478 Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 29 Mar 2008 15:01:34 +0000 X-Mailer: Apple Mail (2.919.2) Subject: [Enum] Unused - dead cat bounce X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --Apple-Mail-14-862427478 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit [Second attempt, this time with files will get through, I hope] Hi Folks, As agreed in PHL, I enclose Jon's review comments on draft-ietf-enum- unused-03. I also enclose a hitherto unpublished unused-04.xml (made in response to comments in YVR). This replaces the -03 version, and uses an http: URI rather than a data: URI. The http: URL could contain a link to the block owner's web site, or the NRA's web site, or other link if required and permitted by the competent NRA, or appropriate definitions of the terms unused and unassigned, or ... If anyone wants the XML source for the -03 version, send me a mail. all the best, Lawrence --Apple-Mail-14-862427478 Content-Disposition: attachment; filename=AD-review-of-draft-ietf-enum-unused.txt Content-Type: text/plain; x-unix-mode=0664; x-mac-type=54455854; name="AD-review-of-draft-ietf-enum-unused.txt" Content-Transfer-Encoding: 7bit From: "Peterson, Jon" Date: 7 January 2008 23:27:07 GMT To: Cc: , Subject: AD review of draft-ietf-enum-unused Before I paste in my review here, just for the sake of Richard and Jim, Lawrence and I discussed this at some length in Vancouver. As I said then, I would really prefer that enum-unused not make use of the "data" URL scheme. Lawrence suggested that it might be possible to return to an HTTP URL instead. I also repeatedly entreated Lawrence to consider trying to flip this problem around (as the last sentence of my review below suggests) or otherwise try to turn this from a problem the DNS does not know how to solve into one that the DNS can solve easily. Ultimately, that may not be possible. Lawrence did ask to see my detailed review notes before further considering this, so, here they are. I understand that a lot of work has gone into this proposal over the years, but I remain skeptical of the underlying requirements, the general architectural direction, and the specific technical solution. The requirements text of 3.4 notes, quite rightly, that in cases 1 and 2, if the call is attempted on the PSTN, and error message will occur. It is also true that a resolver cannot distinguish between cases 4 and 5, and thus the application will not be able to tell whether or not attempting the call on the PSTN would succeed. But my question is this: what is the problem, exactly? A call on the PSTN can fail for a number of reasons that have nothing to do with whether or not a number is allocated - do we need to be able to anticipate all of those conditions too, before we place a call? Of course I agree that in an ideal world, terminals would be able to anticipate that a call would fail before it is placed if the condition is predictable. But I'm not sure it is ENUM's responsibility to know whether or not a call that is placed outside the Internet will succeed. I am also a bit skeptical that the looping behavior described in 3.5 would be instantiated in a reasonable deployment network. Even the most trivial gateways can be provisioned to distinguish number ranges which are considered "local" or "on-net" from those that are reachable through the PSTN. Just because a number cannot be reached over the Internet does not mean that it must be dropped to the PSTN; stipulating that a gateway's routing decision must be based solely on what it learns from ENUM speaks to a gateway implementation problem, not a problem that necessarily needs to be rectified by defining new enumservices. Architecturally, as was the case with previous incarnations of this proposal, this mechanism seems to introduce a DNS response code in the form of an enumservice. The argument of 3.2 and 3.3 is basically "this is why the current RCODEs are not sufficient." The new response code appears as an enumservice because ENUM is where the perceived need for this RCODE has emerged. The idea that a DNS label is "unused" per cases 1, 2 and 6 in Section 3.1 is something for which no RCODE currently exists, though hypothetically one could imagine an RCODE that serves this purpose rather than an enumservice. I am not sure it is within the scope of the ENUM working group to provide new RCODEs or protocol elements that effectively serve the purpose of RCODEs. Certainly this is not something I would feel comfortable doing without substantial review and approval from the DNS community. Since enumservices need to be associated with a regexp or replacement, the "unused" enumservice nominally contains a replacement to a data URI. I really don't feel that the data URI is an architecturally meaningful "replacement" for a telephone number - there is no sense in which transforming a telephone number into a data URI string identifies a resource. The examples in the draft (which include textual strings for "unassigned" and "unallocated") are unabashedly kludgey, and the syntax of the field is left open ("a national matter"). Suffice it to say that all this suggests to me that you don't really need a NAPTR record. There is no Naming Authority pointing going on in this record, even if the data URI seems to warp NAPTRs to the point where they don't signify anything more specific than a TXT record. I feel pretty strongly that populating DNS labels with NAPTR records containing the "unused" service is an undesirable solution to this problem. I wonder, though, if the problem is cast in a way that makes it prohibitively difficult to solve. Did you ever consider flipping this around by applying a flag to particular delegations or labels which would indicate that they are "ENUM-only"? - J --Apple-Mail-14-862427478 Content-Disposition: attachment; filename=draft-ietf-enum-unused-04.xml Content-Type: text/xml; x-mac-creator=21526368; x-unix-mode=0664; x-mac-type=54455854; name="draft-ietf-enum-unused-04.xml" Content-Transfer-Encoding: 7bit IANA Registration for Enumservice UNUSED Oefeg
Postbox 147 1103 Vienna Austria +43-664-420-4100 Richard.stastny@oefeg.at
Siemens Roke Manor Research
Roke Manor Romsey United Kingdom +44-1794-833666 lwc@roke.co.uk
DNS-MODA
6 Langside Court Bothwell SCOTLAND United Kingdom +44 1698 852881 jim@dns-moda.org
Applications ENUM Internet-Draft DNS NAPTR ENUMSERVICE UNUSED E.164 This document registers the Enumservice "unused" using the URI scheme "http:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early".
The Circuit Switched Network (CSN) of which the Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN), and Public Land Mobile Network (PLMN) are part is designed to use E.164 numbers as native global addresses. If a potential caller has an E.164 number, then to place a call using this address he or she needs a way to pass the request either directly or indirectly to systems "in" the CSN for them to forward. ENUM ("E.164 Number Mapping") has introduced a mechanism to find other contact addresses when given an E.164 number. Thus, if the caller (or an agent somewhere in the call path) has access to the global Domain Name System (DNS), they can use ENUM as described in RFC 3761 to find alternative contacts to the E.164 number and place the call using whatever system was indicated in those contacts. In its intended use, an ENUM query would return a set of NAPTR ("Naming Authority Pointer") resource records , and these would be processed to select the appropriate communications contact choices. Each communications contact is held in a URI ("Universal Resource Indicator") generated from the contents of a NAPTR. However, ENUM entries may not exist for a given E.164 number for two reasons. Either the assignee who is entitled to register an ENUM domain associated with the E.164 number they hold has chosen not to request this registration, or the number is not currently allocated or assigned for communications service. In either situation, the caller has no other information and so no alternative to placing the call via the system that uses E.164 numbers as global identifiers; at present, this is the CSN.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
This section describes the problems that arise where the ENUM system does not hold full information on all telephone numbers and clients display typical behaviour. The proposed solution to the problems described here is covered in and in the unused Enumservice registration in .
Traditionally, communications service is provided via a network that uses telephone numbers as global addresses. Examples of such networks are the PSTN, ISDN and PLMN. ENUM registrations are normally allowed only to customers who receive communications service via a telephone number. There may or may not be an ENUM registration when such service is provided. An ENUM registration is usually not permitted when no customer receives service via the corresponding telephone number. When considering ENUM registrations associated with telephone numbers, there are six scenarios: The number is not allocated to a service provider, the number is not currently used by that provider for communications service for a customer, the number is used to provide communications service to a customer and either that customer has not chosen to maintain an ENUM registration associated with that number, or the National Regulatory Authority (NRA) responsible for these numbers does not allow ENUM registrations, the number is used to provide communications service to a customer and that customer has an ENUM registration associated with that number. Communications service may alternatively be provided only by recourse to an ENUM lookup. Such numbers are known as "ENUM only" ranges. For these numbers there are two further possibilities: There is an ENUM registration and that number may be used for communications service, there is no ENUM registration and therefore the number is not used for communications service.
Assuming properly configured name servers and protocol conformant software, an ENUM query on a domain associated with a telephone number may elicit one of several outcomes based on the DNS response. In uses cases 1,2,3,and 6, the DNS response will indicate Name Error (RCODE=3, commonly known as NXDOMAIN, signifying that the domain name referenced in the query does not exist). In use cases 4 and 5, the DNS response will indicate No Error (RCODE=0). There are three possibilities here: There may be at least one usable NAPTR (meaning one in which the Enumservice is supported and the URI is resolved), in which case a communications attempt can be made. Even though the DNS response indicates no error, there may not be any usable NAPTRs in that response. This may happen because the domain owner has chosen not to populate the zone with NAPTR records. This response (RCODE=0, Number of Answers=0) is also known as NOHOST, meaning that the queried name exists but not for the record type that was requested. However, even if there are NAPTRs returned, none of the ones present may be usable. For example, the NAPTR RRSet may include only an "h323" Enumservice, whilst the client node is capable only of processing "sip" or "voice:tel" Enumservices. As it cannot know the case it has encountered, if the client receives a DNS response with no usable NAPTRs or one with RCODE=3, it must decide whether or not to attempt to place the call using other means.
Not every customer has an ENUM registration if provided service via a network that uses telephone numbers natively, and until this is the case, a reasonable strategy has been to attempt to place the call via such a network if it receives an ENUM response with RCODE=3. This is especially true if the National Regulatory Authority has chosen not to permit ENUM registrations at all for the telephone numbers under its control. This may also be the chosen strategy if the client receives a response with RCODE=0 (No Error), but with no usable NAPTRs.
In the case of an ENUM client getting a DNS response with RCODE=3, the semantics of that reply are ambiguous. Is this case 1,2,3, or 6? It is useful for the client to know if this is case 3, as in this case the "default" strategy will succeed. In cases 1 and 2, trying to place the call via a network that uses such numbers natively will result in that network returning an error. However, in case 6 even this cannot be guaranteed. Similarly, if the client finds no usable NAPTRs, is this case 4 or case 5? In the latter case the strategy will fail, whilst in the former case it will succeed.
However, for the "ENUM only" cases, there is a further problem. If the call is placed via a network that uses such numbers natively, it can be processed only via an ENUM lookup, and typically this will involve a gateway from that network performing the lookup and delivering the call onwards based on the response. If that gateway receives a response with RCODE=3 or one including no usable NAPTRs, then employing the "default" strategy (attempting the call via a network that uses these numbers natively) will cause a "loop". The call will be redirected to this network, where it will be routed to a gateway, this gateway will perform a lookup, will receive the same response, will attempt to place the call back to that network, and so on.
We propose an explicit indication of this "number unused" state (as described in points 1,2, and 6 in ). This uses a NAPTR in the zone associated with an unused telephone number, with an Enumservice called "unused" that should be taken as an assertion that the associated E.164 number is not assigned to a subscriber for communications service; it's an unused number. This NAPTR can also be used by a National Regulatory Authority (NRA) to indicate number blocks that it has reserved, and has not allocated to a service provider. It is a matter for individual countries whether or not they will support (or require) information giving the identity of the current "owner" of an E.164 number within their responsibility to be made available via IRIS/WHOIS. Thus it may not be possible to use these protocols to find out the entity responsible for a number or number range concerned, particularly where that number or range is not currently "in use". Since the registration and syntax of a terminal NAPTR for "E2U" Enumservices requires at least one URI scheme to be defined, we propose that the Enumservice "unused" will use an "http:" URI. The content referenced in this "http:" URI is a national matter. For example, it may be used to refer to a resource providing additional information about the reason for the existence of this record, and/or (where required by the competent regulatory authority) the identity of the entity responsible for this number.
Enumservice Name: "unused" Enumservice Type: "unused" Enumservice Subtypes: "data" URI Schemes: "http:" Functional Specification: The proposed solution in . Definition of expected action: When an ENUM lookup for a number explicitly returns the "unused" NAPTR, the response indicates to the client that the number is known to ENUM but there are no implicit communication end-points associated with it. The client can then signal an error to the application or end user instead of then trying and failing to terminate the call on the PSTN, which would have been the typical behaviour of an ENUM-aware VoIP/PSTN gateway if the ENUM lookup had returned a DNS response indicating NXDOMAIN or NOHOST. Thus, if a NAPTR with this Enumservice is received and processed, it indicates that there are no possible communication methods that can be used to reach the end point. The queried E.164 number is currently not allocated, or unassigned to a subscriber for communications service. The recipient SHOULD treat this response as if they had received a "number not in service" indication from a terminating network. Note that the generated URI is not a potential target for any current call. The content referred to in the "http:" URI MUST NOT be used in normal call processing but only if there is a non-call related reason. Security considerations: see . Intended usage: COMMON Authors Lawrence Conroy, Richard Stastny, Jim Reid (for authors contact details see Authors' Addresses section). Any other information that the author deems interesting: None
Unassigned number $ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa. 3.8.0 NAPTR 10 100 "u" "E2U+unused:http"     "!^.*$!http://www.nra.example/static/numbering/cupid.htm?cupid=001!" . This indicates that the controller of the number block +441632960 does not provide telephony service via the number +441632960083; it is not assigned to a subscriber. Unallocated number $ORIGIN 0.6.9.4.5.1.1.4.4.e164.arpa. * NAPTR 10 100 "u" "E2U+unused:http"     "!^.*$!http://www.nra.example/static/numbering/sabc.htm?SABC=1154!" This indicates that the number block +441154960 is not allocated by the NRA to any service provider and therefore no number in this block provides any communication service.
DNS does not make policy decisions about the records that it shares with an inquirer. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM record set must therefore be considered to be open to the public. An analysis of threats specific to the dependence of ENUM on the DNS, and the applicability of DNSSEC ("Domain Name Security") to these, is provided in .
This document requests registration of the "unused" Enumservice with the sub-type "unused:http" according to the guidelines and specifications in RFC 3761 and the definitions in this document. This Enumservice is intended for use with the "http:" URI scheme.
Thanks to Patrik Faltstrom, Michael Mealling and Peter Koch for their thorough feedback, and colleagues in ETSI TISPAN who helped to clarify the operational features during the development of . Thanks also to the members of the ENUM working group for their wide ranging discussions. These have helped to indicate where changes were needed in this document to help explain what is an intrinsically difficult subject. Finally, thanks to Alex Mayrhofer for his useful document review, picking up the remaining issues.
Key words for use in RFCs to Indicate Requirement Levels Harvard University
Holyoke Center, Room 813 1350 Massachusettes Avenue Cambridge MA 02138 US +1 617 495 3864 sob@harvard.edu
The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
The International Public Telecommunication Number Plan ITU-T
Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database
DOMAIN NAMES - CONCEPTS AND FACILITIES
Hypertext Transfer Protocol -- HTTP/1.1
Protocol Modifications for the DNS Security Extensions
Threat Analysis of the Domain Name System (DNS)
Minimum Requirements for Interoperability of ENUM Implementations ETSI
--Apple-Mail-14-862427478 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://www.ietf.org/mailman/listinfo/enum --Apple-Mail-14-862427478-- From enum-bounces@ietf.org Mon Mar 31 19:00:04 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E1028C19E; Mon, 31 Mar 2008 19:00:04 -0700 (PDT) X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AB9C13A6DC4; Mon, 31 Mar 2008 19:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080401020001.AB9C13A6DC4@core3.amsl.com> Date: Mon, 31 Mar 2008 19:00:01 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] I-D Action:draft-ietf-enum-3761bis-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org 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 E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) Author(s) : S. Bradner, et al. Filename : draft-ietf-enum-3761bis-03.txt Pages : 22 Date : 2008-03-31 This document discusses the use of the Domain Name System (DNS) for the storage of E.164 numbers, and for resolving them into URIs that can be used for (for example) telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-3761bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-enum-3761bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-03-31185429.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/enum --NextPart-- From tax@refund.irs.gov Tue Apr 1 07:19:04 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE0653A6A36; Tue, 1 Apr 2008 07:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.756 X-Spam-Level: X-Spam-Status: No, score=-92.756 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_50=0.001, FORGED_MUA_OUTLOOK=3.116, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MSOE_MID_WRONG_CASE=0.82, NORMAL_HTTP_TO_IP=0.001, SARE_HEXOCTDWORD=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D96M+5lcLpGg; Tue, 1 Apr 2008 07:19:04 -0700 (PDT) Received: from mail2.tcdata.it (mail2.tcdata.it [195.31.250.7]) by core3.amsl.com (Postfix) with ESMTP id 6C00C3A6808; Tue, 1 Apr 2008 07:19:03 -0700 (PDT) Received: from static-65-73-136-146.sdsl01.roch.ny.frontiernet.net [65.73.136.146] by mail2.tcdata.it with SMTP; Tue, 1 Apr 2008 16:17:02 +0200 Reply-To: From: "Internal Revenue Service" Subject: Internal Revenue Service Tax Notification Date: Tue, 1 Apr 2008 10:16:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20080401141903.6C00C3A6808@core3.amsl.com> To: undisclosed-recipients:; Internal Revenue Service (IRS) United States Department of the Treasury After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of $184.80. Please submit the tax refund request and allow us 6-9 days in order to process it. A refund can be delayed for a variety of reasons. For example submitting invalid records or applying after the deadline. To access the form for your tax refund, use the following personalized link: http://0xCA.0x27.0x30.0xDD/www.irs.gov/ Regards, Internal Revenue Service Document Reference: (0xCA.0x27.0x30.0xDD). From enum-bounces@ietf.org Tue Apr 1 07:54:45 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A985C28C4B8; Tue, 1 Apr 2008 07:54:45 -0700 (PDT) X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id D250C28C3A8; Tue, 1 Apr 2008 07:54:42 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20080401145442.D250C28C3A8@core3.amsl.com> Date: Tue, 1 Apr 2008 07:54:42 -0700 (PDT) Cc: enum mailing list , enum chair , Internet Architecture Board , RFC Editor Subject: [Enum] Protocol Action: 'A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services' to Proposed Standard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The IESG has approved the following document: - 'A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services ' 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-calendar-service-04.txt Technical Summary This document registers a Telephone Number Mapping (ENUM) service for Internet Calendaring Services. Specifically, this document focuses on provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM. Working Group Summary The document is one of a number of enumservice registrations in the series. The application suggests a mapping of phone number to find a calendaring service. Protocol Quality This document was reviewed for the IESG by Jon Peterson. Richard Shockey is the PROTO Shepherd. GEN-ART review was provided by David Black. Note to RFC Editor In Section 2: OLD: Security considerations: See section 3. NEW: Security considerations: See section 4. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum