From rudolf.brandner@siemens.com Sun, 02 May 2004 18:44:01 -0400 From: Brandner Rudolf Date: Sun, 02 May 2004 18:44:01 -0400 To: enum at ietf.org Subject: [Enum] Heads up on updates on webft and msg drafts Message-ID: <79D5F4B2D775204D9C7852EE41C5477391D50A@mchh2a1e.mchh.siemens.de> MIME-Version: 1.0 Content-Type: text/plain Status: R 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 lwc@roke.co.uk Mon, 03 May 2004 12:57:02 -0400 From: "Conroy, Lawrence (SMTP)" Date: Mon, 03 May 2004 12:57:02 -0400 To: enum at ietf.org Subject: [Enum] In character Message-ID: <3C635602-9D21-11D8-BC05-00039355516C@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R 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 fujiwara@jprs.co.jp Mon, 03 May 2004 14:40:14 -0400 From: fujiwara@jprs.co.jp Date: Mon, 03 May 2004 14:40:14 -0400 To: lwc at roke.co.uk Subject: [Enum] Re: In character In-Reply-To: <3C635602-9D21-11D8-BC05-00039355516C@roke.co.uk> Message-ID: <20040504.033054.41631017.fujiwara@jprs.co.jp> MIME-Version: 1.0 Content-Type: text/plain Status: R 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 lwc@roke.co.uk Mon, 03 May 2004 15:21:03 -0400 From: "Conroy, Lawrence (SMTP)" Date: Mon, 03 May 2004 15:21:03 -0400 To: fujiwara at jprs.co.jp Subject: [Enum] Re: In character In-Reply-To: <3C635602-9D21-11D8-BC05-00039355516C@roke.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Tue, 04 May 2004 02:42:04 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Tue, 04 May 2004 02:42:04 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: [Enum] Re: In character In-Reply-To: <3C635602-9D21-11D8-BC05-00039355516C@roke.co.uk> Message-ID: <49871B1A-9D95-11D8-867A-000A95B2B926@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R 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 _______________________________________________ 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 sdlind@att.com Thu, 20 May 2004 11:47:31 -0400 (EDT) From: "Lind, Steven D, ALABS" Date: Thu, 20 May 2004 11:47:31 -0400 (EDT) To: Subject: [Enum] IP claims that may impact ENUM Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R 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 at att.com Florham Park, NJ 07932 -------------------------------------------------------------------------------- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Thu, 20 May 2004 11:47:32 -0400 (EDT) From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 20 May 2004 11:47:32 -0400 (EDT) To: "Lind, Steven D, ALABS" Subject: [Enum] Re: IP claims that may impact ENUM In-Reply-To: Message-ID: <5EB83986-AA54-11D8-B1C3-000A95B2B926@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R On May 20, 2004, at 13:46, Lind, Steven D, ALABS wrote: 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. 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. 1486 An Experiment in Remote Printing. M. Rose, C. Malamud. July 1993. (Format: TXT=26373 bytes) (Obsoleted by RFC1528, RFC1529) (Status: EXPERIMENTAL) ENUM itself was first documented and implemented as part of a master thesis at Ericsson winter 1996-1997. Patrik Fältström _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Thu, 20 May 2004 12:52:08 -0400 (EDT) From: "Peter Williams" Date: Thu, 20 May 2004 12:52:08 -0400 (EDT) To: enum at ietf.org Subject: RE: [Enum] Re: IP claims that may impact ENUM Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Internet-Drafts@ietf.org Fri, 21 May 2004 16:55:59 -0400 (EDT) From: Internet-Drafts@ietf.org Date: Fri, 21 May 2004 16:55:59 -0400 (EDT) To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-pres-01.txt Message-ID: <200405211955.PAA25740@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R 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 at 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 at 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. From Internet-Drafts@ietf.org Tue, 25 May 2004 16:11:48 -0400 From: Internet-Drafts@ietf.org Date: Tue, 25 May 2004 16:11:48 -0400 To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-msg-01.txt Message-ID: <200405251952.PAA13052@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R 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 ENUMservices email, fax, mms, ems and sms Author(s) : R. Brandner, et al. Filename : draft-ietf-enum-msg-01.txt Pages : 22 Date : 2004-5-25 This document registers the 'ENUMservices' [6] 'email', 'fax', 'sms', 'ems' and 'mms' using the URI schemes 'tel:', 'mailto:', 'sip:' and 'sips:' as per the IANA registration process defined in the ENUM specification RFC3761 [6]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at 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-msg-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-msg-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. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Internet-Drafts@ietf.org Tue, 25 May 2004 16:11:53 -0400 From: Internet-Drafts@ietf.org Date: Tue, 25 May 2004 16:11:53 -0400 To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-webft-01.txt Message-ID: <200405251953.PAA13075@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R 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 ENUMservices web and ft Author(s) : R. Brandner, et al. Filename : draft-ietf-enum-webft-01.txt Pages : 13 Date : 2004-5-25 This document registers the 'ENUMservices' [3] 'web' and 'ft' using the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification RFC3761 [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-webft-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at 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-webft-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-webft-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. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Wed, 26 May 2004 13:47:24 -0400 From: Richard Shockey Date: Wed, 26 May 2004 13:47:24 -0400 To: enum at ietf.org Subject: [Enum] Note on the web and msg ENUMservices drafts. Message-ID: <6.1.0.6.2.20040526133009.03839ec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R These documents have already been approved by the WG. They require no further action on our part. The revised documents represent minor editorial changes requested by the IESG for clarification. They are now in the IESG queue for approval to become Proposed Standards. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From chairman@isoc-id.org Sun, 30 May 2004 11:56:56 -0400 From: Teddy A Purwadi Date: Sun, 30 May 2004 11:56:56 -0400 To: Patrik Fältström Subject: [Enum] Re: IP claims that may impact ENUM In-Reply-To: Message-ID: <6.0.1.1.0.20040529092852.032b3d88@pop3.wireless.net.id> MIME-Version: 1.0 Content-Type: text/plain Status: R At 06:53 PM 5/20/2004, Patrik Fältström wrote: On May 20, 2004, at 13:46, Lind, Steven D, ALABS wrote: 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. Yes. we have to find this clearance by institutional body that in-charged or mandatory institution(s) to do so. ISOC? -teddy 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. 1486 An Experiment in Remote Printing. M. Rose, C. Malamud. July 1993. (Format: TXT=26373 bytes) (Obsoleted by RFC1528, RFC1529) (Status: EXPERIMENTAL) ENUM itself was first documented and implemented as part of a master thesis at Ericsson winter 1996-1997. Patrik Fältström _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From sob@harvard.edu Mon, 31 May 2004 08:02:13 -0400 From: sob@harvard.edu (Scott Bradner) Date: Mon, 31 May 2004 08:02:13 -0400 To: enum at ietf.org Subject: [Enum] Re: IP claims that may impact ENUM Message-ID: <20040531115608.2F35F231790@newdev.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain Status: R The HP patent mentioned in the ITU-T study group 2 contribution is U.S. patent 6,131,095 The original application for this patent was filed on Dec 11, 1996 - which provides a default date of invention of Dec 11, 1995. RFC 1486 was published in July 1993. The only RFC referenced in the patent is RFC 1034. You can see the text of the patent at the US patent office web site type the patent number in the blank on http://patft.uspto.gov/netahtml/srchnum.htm The other IPR is a UK patent application and UK patent GB2365674B I have not figured out how to find the text of UK patents on-line if someone knows please let me know tnx Scott _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Mon, 31 May 2004 09:40:33 -0400 From: Jim Reid Date: Mon, 31 May 2004 09:40:33 -0400 To: sob at harvard.edu (Scott Bradner) Subject: Re: [Enum] Re: IP claims that may impact ENUM In-Reply-To: <20040531115608.2F35F231790@newdev.harvard.edu> Message-ID: <20070.1086010214@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Scott" == Scott Bradner writes: Scott> The other IPR is a UK patent application and UK patent Scott> GB2365674B According to the UK Patent Office web site, this was filed on 26/5/2000. Scott> I have not figured out how to find the text of UK patents Scott> on-line if someone knows please let me know It seems that the actual patents are not available on-line. Though I suspect they are available for a fee. [Her Majesty's Government likes to make public services like the Patent Office pay their own way.] Details of UK patent filings however are available at: http://webdb4.patent.gov.uk/patents In the small print, this web page says that "the Patent Office cannot undertake the free provision of additional information relating to the results you obtain from this service". _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From dmiloshevic@afilias.info Mon, 31 May 2004 11:05:51 -0400 From: "Desiree Miloshevic" Date: Mon, 31 May 2004 11:05:51 -0400 To: "Jim Reid" Subject: RE: [Enum] Re: IP claims that may impact ENUM In-Reply-To: <20070.1086010214@gromit.rfc1035.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R > Scott> The other IPR is a UK patent application and UK patent > Scott> GB2365674B > >According to the UK Patent Office web site, this was filed on 26/5/2000. Jim, how did you get that data? I tried entering the number in the db below and it said publicaiton number invalid? http://webdb4.patent.gov.uk/patents Des -- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Mon, 31 May 2004 11:57:09 -0400 From: Jim Reid Date: Mon, 31 May 2004 11:57:09 -0400 To: dmiloshevic at afilias.info Subject: Re: [Enum] Re: IP claims that may impact ENUM In-Reply-To: Message-ID: <20428.1086018060@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Desiree" == Desiree Miloshevic writes: Desiree> Jim, how did you get that data? I tried entering the Desiree> number in the db below and it said publicaiton number Desiree> invalid? The web site implies Publication Numbers end in digits, not a letter Dropping the trailing 'B' from the reference Scott quoted will work. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Mon, 31 May 2004 21:05:11 -0400 From: Jeff Williams Date: Mon, 31 May 2004 21:05:11 -0400 To: dmiloshevic at afilias.info Subject: Re: [Enum] Re: IP claims that may impact ENUM In-Reply-To: Message-ID: <40BBEEFF.1D029B50@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Desiree and all, The correct filing nmber is GB2365674, without the "B" on the end.. Desiree Miloshevic wrote: > > Scott> The other IPR is a UK patent application and UK patent > > Scott> GB2365674B > > > >According to the UK Patent Office web site, this was filed on 26/5/2000. > > Jim, how did you get that data? > I tried entering the number in the db below and it said publicaiton number > invalid? > > http://webdb4.patent.gov.uk/patents > > Des > -- > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum