From exim@www1.ietf.org Sun May 2 18:52:40 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08532 for ; Sun, 2 May 2004 18:52:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKPlI-0005Jw-VB for enum-archive@odin.ietf.org; Sun, 02 May 2004 18:48:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i42MmePl020401 for enum-archive@odin.ietf.org; Sun, 2 May 2004 18:48:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKPgn-0003tX-9j; Sun, 02 May 2004 18:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKPfs-0003bk-1G for enum@optimus.ietf.org; Sun, 02 May 2004 18:43:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07584 for ; Sun, 2 May 2004 18:42:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKPfo-0002g9-TF for enum@ietf.org; Sun, 02 May 2004 18:43:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKPbr-00023N-00 for enum@ietf.org; Sun, 02 May 2004 18:38:55 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BKPYG-0001LO-00 for enum@ietf.org; Sun, 02 May 2004 18:35:12 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i42MZ6j08275; Mon, 3 May 2004 00:35:06 +0200 (MEST) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i42MZ6M23548; Mon, 3 May 2004 00:35:06 +0200 (MEST) Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id AAA01281; Mon, 3 May 2004 00:34:29 +0200 (MET DST) Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Mon, 3 May 2004 00:35:04 +0200 Message-ID: <79D5F4B2D775204D9C7852EE41C5477391D50A@mchh2a1e.mchh.siemens.de> From: Brandner Rudolf To: enum@ietf.org Cc: "'Richard Shockey'" , paf@cisco.com, Richard Stastny , lwc@roke.co.uk Date: Mon, 3 May 2004 00:34:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Enum] Heads up on updates on webft and msg drafts Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Many congratulations on having got RFC 3761 done. This is the time to update the webft and msg drafts. So I would like to give you a heads up that I am working on an update on the above mentioned drafts. Many thanks, Rudi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon May 3 13:14:38 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14624 for ; Mon, 3 May 2004 13:14:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgt2-0006hL-FU for enum-archive@odin.ietf.org; Mon, 03 May 2004 13:05:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43H5mlc025748 for enum-archive@odin.ietf.org; Mon, 3 May 2004 13:05:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgkY-0004il-7R; Mon, 03 May 2004 12:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgcW-0002Sp-W0 for enum@optimus.ietf.org; Mon, 03 May 2004 12:48:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12884 for ; Mon, 3 May 2004 12:48:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKgcV-0007Zc-4o for enum@ietf.org; Mon, 03 May 2004 12:48:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKgay-0007Lv-00 for enum@ietf.org; Mon, 03 May 2004 12:47:09 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BKgZi-00070h-00 for enum@ietf.org; Mon, 03 May 2004 12:45:51 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 3 May 2004 17:45:13 +0100 Received: from [127.0.0.1] (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JHDWYD4R; Mon, 3 May 2004 17:45:08 +0100 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Cc: fujiwara@jprs.co.jp Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3C635602-9D21-11D8-BC05-00039355516C@roke.co.uk> Content-Transfer-Encoding: 7bit Date: Mon, 3 May 2004 17:45:07 +0100 X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Enum] In character Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Folks, To prove that I have not disappeared and *am* working on the BCP, herewith some text on the choice of RegExp field delimiter character. I expect that I've missed something, but if I read another document on character sets my eyes will fall out. In short, as '!' is a valid character inside a URI and thus may appear in the replacement (sed-style substitution expression) sub-field, I'm not sure if we should use this. My current "least bad" choice seems to be '"' (i.e. 0x0022). I had thought that this can appear in a mailto: URI, but according to RFC2396 (which specifies URI syntax) it can't. Comments appreciated. Lawrence -------------------------------------------------------- RegExp field delimiter choice: There are a number of interacting details in the operation of the RegExp field of a NAPTR that define the choice of delimiter, over and above the plain specification in RFC3402 ss 3.2. ---- As the match sub-field will be a Posix Regular Expression (PRE), the delimiter should not be a character that could reasonablyu appear within a PRE that operates on the ENUM Application Unique String. These characters include the PRE-reserved set: |()*+?{}0123456789,.^$\-=<>: plus the classes defined in ctype: alnum digit punct alpha graph space blank lower upper cntrl print xdigit In short, this is every possible character. However, there are some practical restrictions placed on semantically correct PRE within an E2U (ENUM) NAPTR. The Application Unique String (against which the PRE is matched) consists of an .E.164 number excluding any non-digit characters, preceded by the character '+', so, in the particular case of the E2U DDDS application, one would expect only characters in the PRE-reserved set to appear in the RegExp match sub-field. Thus, it would seem that the RegExp sub-field delimiter SHOULD NOT be in the PRE-reserved set of characters. ---- Where used to produce a URI (as in the 'E2U' DDDS application defined for ENUM), the replacement sub-field may contain a URI. To avoid ambiguity, the RegExp sub-field delimiter will need to be different from a valid character that may appear in a URI. Thus the RegExp field delimiter SHOULD be in the list of characters excluded from a URI (in section 2.4.3 of RFC2396) - these are defined there as control, space, delims, and unwise sets. Conversely, a URI may have a fragment indicator, so that the character '#', whilst defined in the URI delims set, should not be used. Similarly, the character '%' may appear in a URI so that even though it is defined in the URI delims set, it should not be used. ---- RFC3402 ss 3.2 specifies that the delimiter may be any octet not in POS-DIGIT or flags sets, further specifies that POS-DIGIT set is the characters 0-9, and that the flags set consists of the character 'i'. In addition, the delimiter should NOT be the SED-style escape character '\', as this may be present and will be processed prior to generation of the URI. ---- Finally, whilst RFC3403 (defining the DDDS DNS database and so the NAPTR syntax) and RFC3761 (defining ENUM) both specifiy that UTF-8 is used as the character set, it is convenient to use a single-octet character for the delimiter (if only to simplify implementation of initial field parsing). With UTF-8, this means that the character will have to be in the US-ASCII equivalent coding space (i.e. a character in the range 0x0000 - 0x007F). Given that many implementations of ENUM clients will use null-terminated string processing functions, the choice of 0x0000 as the delimiter unnecessarily complicates processing; thus for convenience the NUL character (\000) SHOULD NOT be used as the sub-field delimiter. ---- Combining these restrictions, as a general rule the delimiter should be: o NOT 0x0000 o in US-ASCII (single octet) range o NOT PRE-reserved (which subsumes that SED-reserved range) PRE-reserved = |()*+?{}0123456789,.^$\-=[]<>: o in URI (control, space, delims, and unwise) sets control = space = delims = "<" | ">" | <"> unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" Note that the delimiter often used in DDDS/NAPTR/ENUM examples ('!') is valid in URIs and so, strictly, should not be used; it is in the mark set and so part of the unreserved character set that may appear within a URI. Of these, one of the few reasonable characters that do not appear to clash with PRE, URI, or sed-style substitutions is the '"' character. This is inconvenient, as it is reserved in many zone file processing tools. However, it should not clash with the other potential elements in a RegExp field, and so it is a valid choice. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon May 3 15:07:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21534 for ; Mon, 3 May 2004 15:07:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKii4-0004oN-4x for enum-archive@odin.ietf.org; Mon, 03 May 2004 15:02:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43J2a3g018476 for enum-archive@odin.ietf.org; Mon, 3 May 2004 15:02:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiMQ-0004gk-F7; Mon, 03 May 2004 14:40:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiGE-0002ZA-5b for enum@optimus.ietf.org; Mon, 03 May 2004 14:33:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18932 for ; Mon, 3 May 2004 14:33:46 -0400 (EDT) From: fujiwara@jprs.co.jp Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKiGB-0003UR-F5 for enum@ietf.org; Mon, 03 May 2004 14:33:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiFL-0003Nv-00 for enum@ietf.org; Mon, 03 May 2004 14:32:56 -0400 Received: from sender2.jprs.co.jp ([61.120.151.69]) by ietf-mx with esmtp (Exim 4.12) id 1BKiEi-00038d-00 for enum@ietf.org; Mon, 03 May 2004 14:32:16 -0400 Received: from alias.jprs.co.jp (alias.jprs.co.jp [192.168.102.41]) by sender2.jprs.co.jp (8.11.6/8.11.6) with ESMTP id i43IUtL04585; Tue, 4 May 2004 03:30:56 +0900 Received: from unix01.jprs.co.jp (unix01.jprs.co.jp [192.168.118.11]) by alias.jprs.co.jp (8.11.7p1+Sun/8.11.7) with ESMTP id i43IUt312859; Tue, 4 May 2004 03:30:55 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by unix01.jprs.co.jp (8.11.6/8.11.6) with ESMTP id i43IUts27410; Tue, 4 May 2004 03:30:55 +0900 Date: Tue, 04 May 2004 03:30:54 +0900 (JST) Message-Id: <20040504.033054.41631017.fujiwara@jprs.co.jp> To: lwc@roke.co.uk Cc: enum@ietf.org In-Reply-To: <3C635602-9D21-11D8-BC05-00039355516C@roke.co.uk> References: <3C635602-9D21-11D8-BC05-00039355516C@roke.co.uk> X-Mailer: Mew version 4.0.64 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Enum] Re: In character Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Conroy-san, enum-wg folks, RFC3402 page 7, 3.2 Substitution Expression Syntax contains: Since escaped occurrences of the delimiter character will be interpreted as occurrences of that character, digits MUST NOT be used as delimiters. So, My understanding is that a URI which contains '!' character may appear in the replacement sub-field as '\!' when '!' is a delimiter character. # escape is easy to parse. For example, URI = "http://member.wide.ad.jp/~fujiwara/#!" then REGEXP field may be "!^.*$!http://member.wide.ad.jp/~fujiwara/#\!!" I think delimiter character should be limited to '!' in ENUM. '"' should not be used as a delimiter character. Because many server softwares and programing languages use '"' as a special character. RFC3403, RFC3761 use '"' as a string delimiter character. -- Fujiwara, Kazunori JPRS > From: "Conroy, Lawrence (SMTP)" > Hi Folks, > To prove that I have not disappeared and *am* working on the BCP, > herewith some text > on the choice of RegExp field delimiter character. I expect that I've > missed something, > but if I read another document on character sets my eyes will fall out. > > In short, as '!' is a valid character inside a URI and thus may appear > in the > replacement (sed-style substitution expression) sub-field, I'm not sure > if we > should use this. > > My current "least bad" choice seems to be '"' (i.e. 0x0022). I had > thought that this can > appear in a mailto: URI, but according to RFC2396 (which specifies URI > syntax) it can't. > > Comments appreciated. > > Lawrence > > -------------------------------------------------------- > RegExp field delimiter choice: > > There are a number of interacting details in the operation of the > RegExp field of a NAPTR that define the choice of delimiter, over and > above the plain specification in RFC3402 ss 3.2. > > ---- > > As the match sub-field will be a Posix Regular Expression (PRE), the > delimiter should not be a character that could reasonablyu appear > within a PRE that operates on the ENUM Application Unique String. > > These characters include the PRE-reserved set: > |()*+?{}0123456789,.^$\-=<>: > plus the classes defined in ctype: > alnum digit punct > alpha graph space > blank lower upper > cntrl print xdigit > In short, this is every possible character. > > However, there are some practical restrictions placed on semantically > correct PRE within an E2U (ENUM) NAPTR. > > The Application Unique String (against which the PRE is matched) > consists of an .E.164 number excluding any non-digit characters, > preceded by the character '+', so, in the particular case of the E2U > DDDS application, one would expect only characters in the PRE-reserved > set to appear in the RegExp match sub-field. > > Thus, it would seem that the RegExp sub-field delimiter SHOULD NOT be > in the PRE-reserved set of characters. > > ---- > > Where used to produce a URI (as in the 'E2U' DDDS application defined > for ENUM), the replacement sub-field may contain a URI. > To avoid ambiguity, the RegExp sub-field delimiter will need to be > different from a valid character that may appear in a URI. > > Thus the RegExp field delimiter SHOULD be in the list of characters > excluded from a URI (in section 2.4.3 of RFC2396) - these are defined > there as control, space, delims, and unwise sets. > > Conversely, a URI may have a fragment indicator, so that the character > '#', whilst defined in the URI delims set, should not be used. > Similarly, the character '%' may appear in a URI so that even though it > is defined in the URI delims set, it should not be used. > > ---- > RFC3402 ss 3.2 specifies that the delimiter may be any octet not in > POS-DIGIT or flags sets, further specifies that POS-DIGIT set is the > characters 0-9, and that the flags set consists of the character 'i'. > > In addition, the delimiter should NOT be the SED-style escape character > '\', as this may be present and will be processed prior to generation > of the URI. > > ---- > > Finally, whilst RFC3403 (defining the DDDS DNS database and so the > NAPTR syntax) and RFC3761 (defining ENUM) both specifiy that UTF-8 is > used as the character set, it is convenient to use a single-octet > character for the delimiter (if only to simplify implementation of > initial field parsing). With UTF-8, this means that the character will > have to be in the US-ASCII equivalent coding space (i.e. a character in > the range 0x0000 - 0x007F). > > Given that many implementations of ENUM clients will use > null-terminated string processing functions, the choice of 0x0000 as > the delimiter unnecessarily complicates processing; thus for > convenience the NUL character (\000) SHOULD NOT be used as the > sub-field delimiter. > > ---- > > Combining these restrictions, as a general rule the delimiter should be: > o NOT 0x0000 > o in US-ASCII (single octet) range > o NOT PRE-reserved (which subsumes that SED-reserved range) > PRE-reserved = |()*+?{}0123456789,.^$\-=[]<>: > o in URI (control, space, delims, and unwise) sets > control = > space = > delims = "<" | ">" | <"> > unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" > > Note that the delimiter often used in DDDS/NAPTR/ENUM examples ('!') is > valid in URIs and so, strictly, should not be used; it is in the mark > set and so part of the unreserved character set that may appear within > a URI. > > Of these, one of the few reasonable characters that do not appear to > clash with PRE, URI, or sed-style substitutions is the '"' character. > This is inconvenient, as it is reserved in many zone file processing > tools. However, it should not clash with the other potential elements > in a RegExp field, and so it is a valid choice. > > -- > > Visit our website at www.roke.co.uk > > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is confidential to > Roke Manor Research Ltd and must not be passed to any third party without > permission. This communication is for information only and shall not create or > change any contractual relationship. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon May 3 15:38:27 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24630 for ; Mon, 3 May 2004 15:38:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjC8-0006R0-I7 for enum-archive@odin.ietf.org; Mon, 03 May 2004 15:33:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43JXe5J024735 for enum-archive@odin.ietf.org; Mon, 3 May 2004 15:33:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKizv-00040i-Rr; Mon, 03 May 2004 15:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKisx-0000c0-IQ for enum@optimus.ietf.org; Mon, 03 May 2004 15:13:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22477 for ; Mon, 3 May 2004 15:13:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKisw-0000e1-C3 for enum@ietf.org; Mon, 03 May 2004 15:13:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiry-0000YC-00 for enum@ietf.org; Mon, 03 May 2004 15:12:51 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BKird-0000Sk-00 for enum@ietf.org; Mon, 03 May 2004 15:12:29 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 3 May 2004 20:11:58 +0100 Received: from [127.0.0.1] (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JHDWYDYC; Mon, 3 May 2004 20:11:56 +0100 From: "Conroy, Lawrence (SMTP)" To: fujiwara@jprs.co.jp Cc: enum@ietf.org In-Reply-To: <20040504.033054.41631017.fujiwara@jprs.co.jp> References: <3C635602-9D21-11D8-BC05-00039355516C@roke.co.uk> <20040504.033054.41631017.fujiwara@jprs.co.jp> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Date: Mon, 3 May 2004 20:11:55 +0100 X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Enum] Re: In character Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Fujiwara-san, folks, I'm happy with this (we use '!' as well :). My only concern is whether or not use of '!' as a delimiter should be mandatory - my feeling is that it SHOULD be used, not that it MUST be used. I'd appreciate comments from anyone else "out there" before we commit to this in the BCP, so... three increasingly specific questions (with my notes in parentheses)::: (i) If anyone objects to the requirement that the server/zone generator MUST use a SED-style escape if a delimiter character appears in the body of the replacement sub-field, PLEASE SPEAK NOW (this one suggests that there may be a conflict, but such a conflict is dealt with by SED escape). (ii) If anyone objects to the statement that a NAPTR RegExp field MUST NOT use a character not in the US-ASCII equivalent range of UTF-8, PLEASE SPEAK NOW (!!!note that I propose that this is MANDATORY!!! - I think that this is a "needed clarification") (outside the URI text in the replacement sub-field, the only place I can see that a multi-octet character would be used is in the sub-field delimiter) (iii) If anyone has an objection to RECOMMENDing that the '!' character SHOULD BE used as the RegExp delimiter, PLEASE SPEAK NOW (note that a client should still be able to process a RegExp that does NOT use the '!' (0x0021) character as a delimiter - it's recommended, not mandatory) all the best, Lawrence On 3 May 2004, at 7:30 pm, fujiwara@jprs.co.jp wrote: > Hi, Conroy-san, enum-wg folks, > > RFC3402 page 7, 3.2 Substitution Expression Syntax contains: > Since escaped occurrences of the delimiter character will be > interpreted as occurrences of that character, digits MUST NOT > be used as delimiters. > > So, My understanding is that a URI which contains '!' character may > appear in the replacement sub-field as '\!' when '!' is a delimiter > character. > > # escape is easy to parse. > > For example, > > URI = "http://member.wide.ad.jp/~fujiwara/#!" > then > REGEXP field may be "!^.*$!http://member.wide.ad.jp/~fujiwara/#\!!" > > I think delimiter character should be limited to '!' in ENUM. > > '"' should not be used as a delimiter character. Because many server > softwares and programing languages use '"' as a special character. > RFC3403, RFC3761 use '"' as a string delimiter character. > > -- > Fujiwara, Kazunori JPRS > >> From: "Conroy, Lawrence (SMTP)" >> Hi Folks, >> To prove that I have not disappeared and *am* working on the BCP, >> herewith some text >> on the choice of RegExp field delimiter character. I expect that I've >> missed something, >> but if I read another document on character sets my eyes will fall >> out. >> >> In short, as '!' is a valid character inside a URI and thus may appear >> in the replacement (sed-style substitution expression) sub-field, I'm >> not sure >> if we should use this. >> >> My current "least bad" choice seems to be '"' (i.e. 0x0022). I had >> thought that this can appear in a mailto: URI, but according to >> RFC2396 (which specifies URI >> syntax) it can't. >> >> Comments appreciated. >> >> Lawrence >> > sets for the RegExp content> _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue May 4 02:50:34 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12442 for ; Tue, 4 May 2004 02:50:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKtiM-0007Ud-1L for enum-archive@odin.ietf.org; Tue, 04 May 2004 02:47:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i446lb2N028803 for enum-archive@odin.ietf.org; Tue, 4 May 2004 02:47:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKtcy-00069o-P1; Tue, 04 May 2004 02:42:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKtZX-0005EN-NC for enum@optimus.ietf.org; Tue, 04 May 2004 02:38:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12009 for ; Tue, 4 May 2004 02:38:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKtZU-0005NF-0d for enum@ietf.org; Tue, 04 May 2004 02:38:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKtYU-0005Bw-00 for enum@ietf.org; Tue, 04 May 2004 02:37:27 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BKtXc-0004qr-00 for enum@ietf.org; Tue, 04 May 2004 02:36:32 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 04 May 2004 08:44:26 +0200 X-BrightmailFiltered: true Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i446Zqbp009048; Tue, 4 May 2004 08:35:59 +0200 (MEST) Received: from xfe-ams-331.cisco.com ([144.254.231.72]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 May 2004 08:35:55 +0200 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 May 2004 08:35:54 +0200 In-Reply-To: References: <3C635602-9D21-11D8-BC05-00039355516C@roke.co.uk> <20040504.033054.41631017.fujiwara@jprs.co.jp> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <49871B1A-9D95-11D8-867A-000A95B2B926@cisco.com> Content-Transfer-Encoding: 7bit Cc: fujiwara@jprs.co.jp, enum@ietf.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] Re: In character Date: Tue, 4 May 2004 08:35:51 +0200 To: "Conroy, Lawrence (SMTP)" X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 04 May 2004 06:35:54.0897 (UTC) FILETIME=[0D30A010:01C431A2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit As we decided in Seoul, when you, Lawrence, have an updated version of your document, myself and Michael will go through it and come with compiled comments. paf On May 3, 2004, at 21:11, Conroy, Lawrence (SMTP) wrote: > Hi Fujiwara-san, folks, > I'm happy with this (we use '!' as well :). > My only concern is whether or not use of '!' as a delimiter should be > mandatory - > my feeling is that it SHOULD be used, not that it MUST be used. > > I'd appreciate comments from anyone else "out there" before we commit > to this in the > BCP, so... three increasingly specific questions (with my notes in > parentheses)::: > > (i) If anyone objects to the requirement that the server/zone > generator MUST use a SED-style escape if a delimiter character > appears in the body of the replacement sub-field, > PLEASE SPEAK NOW > > (this one suggests that there may be a conflict, but such a conflict > is dealt > with by SED escape). > > (ii) If anyone objects to the statement that a NAPTR RegExp field MUST > NOT use a character not in the US-ASCII equivalent range of > UTF-8, > PLEASE SPEAK NOW > > (!!!note that I propose that this is MANDATORY!!! - I think that this > is > a "needed clarification") > > (outside the URI text in the replacement sub-field, the only place I > can > see that a multi-octet character would be used is in the sub-field > delimiter) > > (iii) If anyone has an objection to RECOMMENDing that the '!' character > SHOULD BE used as the RegExp delimiter, > PLEASE SPEAK NOW > > (note that a client should still be able to process a RegExp that does > NOT use > the '!' (0x0021) character as a delimiter - it's recommended, not > mandatory) > > all the best, > Lawrence > > On 3 May 2004, at 7:30 pm, fujiwara@jprs.co.jp wrote: > >> Hi, Conroy-san, enum-wg folks, >> >> RFC3402 page 7, 3.2 Substitution Expression Syntax contains: >> Since escaped occurrences of the delimiter character will be >> interpreted as occurrences of that character, digits MUST NOT >> be used as delimiters. >> >> So, My understanding is that a URI which contains '!' character may >> appear in the replacement sub-field as '\!' when '!' is a delimiter >> character. >> >> # escape is easy to parse. >> >> For example, >> >> URI = "http://member.wide.ad.jp/~fujiwara/#!" >> then >> REGEXP field may be "!^.*$!http://member.wide.ad.jp/~fujiwara/#\!!" >> >> I think delimiter character should be limited to '!' in ENUM. >> >> '"' should not be used as a delimiter character. Because many server >> softwares and programing languages use '"' as a special character. >> RFC3403, RFC3761 use '"' as a string delimiter character. >> >> -- >> Fujiwara, Kazunori JPRS >> >>> From: "Conroy, Lawrence (SMTP)" >>> Hi Folks, >>> To prove that I have not disappeared and *am* working on the BCP, >>> herewith some text >>> on the choice of RegExp field delimiter character. I expect that >>> I've missed something, >>> but if I read another document on character sets my eyes will fall >>> out. >>> >>> In short, as '!' is a valid character inside a URI and thus may >>> appear >>> in the replacement (sed-style substitution expression) sub-field, >>> I'm not sure >>> if we should use this. >>> >>> My current "least bad" choice seems to be '"' (i.e. 0x0022). I had >>> thought that this can appear in a mailto: URI, but according to >>> RFC2396 (which specifies URI >>> syntax) it can't. >>> >>> Comments appreciated. >>> >>> Lawrence >>> >> sets for the RegExp content> > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu May 20 11:47:31 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25808 for ; Thu, 20 May 2004 11:47:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpIw-0007BX-3l for enum-archive@odin.ietf.org; Thu, 20 May 2004 11:17:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KFHsSj027559 for enum-archive@odin.ietf.org; Thu, 20 May 2004 11:17:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQp5y-0004Fx-UU; Thu, 20 May 2004 11:04:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQm3Y-0001Xh-61 for enum@optimus.ietf.org; Thu, 20 May 2004 07:49:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12960 for ; Thu, 20 May 2004 07:49:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQm3X-0004QZ-9s for enum@ietf.org; Thu, 20 May 2004 07:49:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQm2W-0004Dv-00 for enum@ietf.org; Thu, 20 May 2004 07:48:45 -0400 Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BQm1g-0003qq-00 for enum@ietf.org; Thu, 20 May 2004 07:47:52 -0400 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i4KBkLCS028001 for ; Thu, 20 May 2004 07:47:22 -0400 Received: from KCCLUST05EVS1.ugd.att.com (135.38.164.86) by attrh3i.attrh.att.com (6.5.032) id 408BE1D300578786; Thu, 20 May 2004 07:47:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 May 2004 06:46:29 -0500 Message-ID: Thread-Topic: IP claims that may impact ENUM Thread-Index: AcQ+YBlC3wbxeDuKS8SrToVkFHLwgg== From: "Lind, Steven D, ALABS" To: Cc: "ENUMF GEN LIST" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Enum] IP claims that may impact ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Internet Management Systems, Inc. (a Swiss company) has submitted a = contribution to the current meeting of ITU-T Study Group 2 that claims = that both they and HP have intellectual property and patents dealing = with the mapping of telephone numbers to internet domain names. I = couldn't find any IP statement on the IETF web site, although that is = not the relevant issue. I wanted to make the WG members aware of this = issue so that they can fold in any impact of this in their business = plans. Steve Lind -------------------------------------------------------------------------= ------- Steven D. Lind Tel: 973-236-6787 180 Park Avenue Fax: 360-343-2875 Room A201 sdlind@att.com Florham Park, NJ 07932 -------------------------------------------------------------------------= ------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu May 20 11:47:32 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25825 for ; Thu, 20 May 2004 11:47:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpIw-0007Ba-3x for enum-archive@odin.ietf.org; Thu, 20 May 2004 11:17:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KFHsLt027560 for enum-archive@odin.ietf.org; Thu, 20 May 2004 11:17:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQp60-0004Ie-SN; Thu, 20 May 2004 11:04:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQmA9-0002qu-UV for enum@optimus.ietf.org; Thu, 20 May 2004 07:56:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13190 for ; Thu, 20 May 2004 07:56:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQmA8-0005mJ-KQ for enum@ietf.org; Thu, 20 May 2004 07:56:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQm9A-0005aQ-00 for enum@ietf.org; Thu, 20 May 2004 07:55:37 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BQm8M-0005DQ-00 for enum@ietf.org; Thu, 20 May 2004 07:54:46 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 May 2004 13:58:55 +0200 X-BrightmailFiltered: true Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4KBqf4L004864; Thu, 20 May 2004 13:54:12 +0200 (MEST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 20 May 2004 13:54:02 +0200 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 May 2004 13:54:01 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <5EB83986-AA54-11D8-B1C3-000A95B2B926@cisco.com> Content-Transfer-Encoding: quoted-printable Cc: ENUMF GEN LIST , enum@ietf.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 20 May 2004 13:53:55 +0200 To: "Lind, Steven D, ALABS" X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 20 May 2004 11:54:01.0774 (UTC) FILETIME=[2476ECE0:01C43E61] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Enum] Re: IP claims that may impact ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On May 20, 2004, at 13:46, Lind, Steven D, ALABS wrote: > Internet Management Systems, Inc. (a Swiss company) has submitted a=20 > contribution to the current meeting of ITU-T Study Group 2 that claims=20= > that both they and HP have intellectual property and patents dealing=20= > with the mapping of telephone numbers to internet domain names. I=20 > couldn't find any IP statement on the IETF web site, although that is=20= > not the relevant issue. I wanted to make the WG members aware of this=20= > issue so that they can fold in any impact of this in their business=20 > plans. FYI: ENUM is using ideas from RFC 1486 published in July 1993 (which=20 means Internet Drafts and testing were going on long before that date)=20= which imply any patent claims talking about mapping of E.164 to domain=20= names have to be filed before that date. The document specifies the=20 tpc.int domain as root. So, ENUM was not where this mapping was=20 invented. 1486 An Experiment in Remote Printing. M. Rose, C. Malamud. July 1993. (Format: TXT=3D26373 bytes) (Obsoleted by RFC1528, RFC1529) = (Status: EXPERIMENTAL) ENUM itself was first documented and implemented as part of a master=20 thesis at Ericsson winter 1996-1997. Patrik F=E4ltstr=F6m _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu May 20 12:52:08 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01310 for ; Thu, 20 May 2004 12:52:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqWl-0002DO-LG for enum-archive@odin.ietf.org; Thu, 20 May 2004 12:36:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGaFHW008515 for enum-archive@odin.ietf.org; Thu, 20 May 2004 12:36:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqBQ-0003L9-Gi; Thu, 20 May 2004 12:14:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpum-000466-2A for enum@optimus.ietf.org; Thu, 20 May 2004 11:57:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27003 for ; Thu, 20 May 2004 11:56:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpuk-0000Bm-Qf for enum@ietf.org; Thu, 20 May 2004 11:56:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQptt-00008e-00 for enum@ietf.org; Thu, 20 May 2004 11:56:05 -0400 Received: from bay3-f4.bay3.hotmail.com ([65.54.169.4] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BQptQ-00003e-00 for enum@ietf.org; Thu, 20 May 2004 11:55:37 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 20 May 2004 08:55:06 -0700 Received: from 66.214.219.37 by by3fd.bay3.hotmail.msn.com with HTTP; Thu, 20 May 2004 15:55:06 GMT X-Originating-IP: [66.214.219.37] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: "Peter Williams" To: enum@ietf.org Subject: RE: [Enum] Re: IP claims that may impact ENUM Date: Thu, 20 May 2004 08:55:06 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 May 2004 15:55:06.0583 (UTC) FILETIME=[D2299E70:01C43E82] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , E.164 attributes were in X.500 1988 Directory standard, as personal phone number listings, and as components of PSAP addresses (in the IETF profile). Domain names were added to the X.500 RFCs about 1990, by Steve Kille, internal documents much earlier. Mashall went one step further, with his experimental fax/printing stuff. There were several messaging/fax services that used complex directory lookups and iterative knowledge discovery processes (rather like ENUM) - to switch outbound channel - phone, SMTP, telex etc. There were also experiments to populate a DNS database from the Directory, and sync up - to make provisioning manageable. most of these were CEC funded projects, so formal deliverables exist. Every IETF standard deployement effort, for any scheme of any value, is going to be hit now by the European software patents opportunity. Europe is just catching up with the US, in this regard. Remember, unlike IETF, the ISO process always had explicit political goals - standardization for itself (of unworkable, never implemented OSI protocols) had value in itself - to form markets, create opportunities, and establish prioir art under the special class: international law. I have a very large library of older documents in trusted directory, untrsted directory security using certs, knowledge and discovery processes (mainly tree walking for secure path discovery). It could help address the most general patent claims; (This is my personal library, not VeriSign property, note.) If HP have actually invented something than makes their ENUM* better than the general model, then good luck to them. Peter. >FYI: ENUM is using ideas from RFC 1486 published in July 1993 (which means >Internet Drafts and testing were going on long before that date) which >imply any patent claims talking about mapping of E.164 to domain names have >to be filed before that date. The document specifies the tpc.int domain as >root. So, ENUM was not where this mapping was invented. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri May 21 16:55:59 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02420 for ; Fri, 21 May 2004 16:55:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRGru-0000iv-QC for enum-archive@odin.ietf.org; Fri, 21 May 2004 16:43:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LKhoD3002747 for enum-archive@odin.ietf.org; Fri, 21 May 2004 16:43:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRG9E-0007QR-FB; Fri, 21 May 2004 15:57:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRG7T-0006sy-4T for enum@optimus.ietf.org; Fri, 21 May 2004 15:55:51 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25740; Fri, 21 May 2004 15:55:48 -0400 (EDT) Message-Id: <200405211955.PAA25740@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: enum@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 21 May 2004 15:55:47 -0400 Subject: [Enum] I-D ACTION:draft-ietf-enum-pres-01.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : Enumservice Registration for Presence Services Author(s) : J. Peterson Filename : draft-ietf-enum-pres-01.txt Pages : 8 Date : 2004-5-21 This document registers an ENUM service for presence. Specifically, this document focuses on provisioning pres URIs in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-pres-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-pres-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-pres-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-21155720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-pres-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-pres-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-21155720.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum