From enum-bounces@ietf.org Fri Aug 03 05:07:58 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IGt8E-0007C0-OG; Fri, 03 Aug 2007 05:07:38 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IGt8D-0007Bv-7W
	for enum@ietf.org; Fri, 03 Aug 2007 05:07:37 -0400
Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGt8C-0003Aw-Fw
	for enum@ietf.org; Fri, 03 Aug 2007 05:07:37 -0400
Received: from [10.10.0.127] (nat.labs.nic.at [::ffff:83.136.33.3])
	(AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
	by pahula with esmtp; Fri, 03 Aug 2007 11:07:31 +0200
	id 0006C17C.46B2F053.000077F6
Message-ID: <46B2EFB9.70107@enum.at>
Date: Fri, 03 Aug 2007 11:04:57 +0200
From: Alexander Mayrhofer <alexander.mayrhofer@enum.at>
Organization: enum.at GmbH
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "'enum@ietf.org'" <enum@ietf.org>, Ed Guy <edguy@emcsw.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: 
Subject: [Enum] review of draft-ietf-enum-iax-03
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


I've done a review of draft-ietf-enum-iax-03 (NITS and more), comments as
follows:

- Generally, i'd appreciate more review of the document before (or at least
while) we last call this - i have the impression the draft has received
limited attention so far, and more eyes simply see more...

- NITS: the idnits report has some issues with the current version, see
http://tools.ietf.org/wg/enum/draft-ietf-enum-iax/draft-ietf-enum-iax-03.nits.txt

(the most important issue is likely the non-use of RFC2119 language - if
this is intended, the "terminology" section is to be removed from the draft)

- The title says "IAX Enumservice", while the Abstract says "IAX2
Enumservice". I think that should be corrected in the Abstract - the acronym
does not need to be expanded there, according to RFC editor policies.

- Please change section 3 title to "Enumservice Registration - IAX" (that
was accepted by the RFC editors in recent registrations, i think we should
keep those documents similar)

- Terminology is never referred to (see idnits)

- Introduction: I have a slight preference to removing some text from there
to make it more concise, namely:
  - first paragraph, last sentence ("This is accomplished..."). This does
not add much information, and might not be true in all deployments (private
ENUM?)
  - Unsure whether text about the DDDS (last paragraph) is necessary -
refering to ENUM itself should be enough, i think.

- Please expand the Acronym "IAX2" in that section, rather than in the
abstract. Please also add a reference to the protocol spec here, like in
section 3.

- Seciton 3 (registration):
  - Small formatting nit: please add blanklines after each registration
parameter. Personally, i did that using

  <t>Enumservice Name: ...</t>
  ..
  <t>Functional Specification:
    <list style='empty'>
      <t>spec text here</t>
    </list>
  </t>

(if that draft is made using xml2rfc)

- Please use quotes also around the subtype name

- Section 4.1: suggest to uppercase "enumservice" to "Enumservice", and to
split the NAPTR record in two lines, either using backslash, or parentheses.
Probably right before the replacement string. If the term "identifier" has
it's dedicated description in the IAX spec, please refer to the respective
section, so that it can be looked up.

- Section 4.2:
  - H.323 should refer to RFC 3762, rather than 3764.
  - the text mentions an Enumservice for mail/SMTP, however, the example
doesn't list it.
  - the text mentions "voice" only, while the Enumservices listed can be
used for generic communication over those three protocols. Maybe a leftover
from using "voice:sip"?
  - The IAX Enumservice in the example is missing the "iax2" subtype.

- Section 4.3:
  - again, i'd prefer having "Enumservice" instead of "enumservice"...
  - If "context" is described in the IAX spec, please refer to the
respective section
  - Please don't split the NAPTR record in the middle of the replacement
field. backslash/parentheses would help.

- Section 4.4:
  - please split this record in a different way, too.

- Section 6: small nit: suggest to use "and the definitions in Section 3 of
this document"...

- References: I think that the DDDS refs are informative only (if you intend
to keep the DDDS text in the introduction in at all)

Hope that helps!

Alex

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



From enum-bounces@ietf.org Tue Aug 07 20:37:49 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IIZWo-0007Yv-LX; Tue, 07 Aug 2007 20:35:58 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IIZWm-0007WQ-Sv; Tue, 07 Aug 2007 20:35:56 -0400
Received: from bosco.isi.edu ([128.9.168.207])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IIZWm-0005R3-F2; Tue, 07 Aug 2007 20:35:56 -0400
Received: by bosco.isi.edu (Postfix, from userid 70)
	id D2B0FDF444; Tue,  7 Aug 2007 17:35:34 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20070808003534.D2B0FDF444@bosco.isi.edu>
Date: Tue,  7 Aug 2007 17:35:34 -0700 (PDT)
X-Spam-Score: -15.0 (---------------)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: enum@ietf.org, rfc-editor@rfc-editor.org
Subject: [Enum] RFC 4979 on IANA Registration for Enumservice 'XMPP'
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


A new Request for Comments is now available in online RFC libraries.

        
        RFC 4979

        Title:      IANA Registration for Enumservice 'XMPP' 
        Author:     A. Mayrhofer
        Status:     Standards Track
        Date:       August 2007
        Mailbox:    alexander.mayrhofer@enum.at
        Pages:      7
        Characters: 11719
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-enum-xmpp-02.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4979.txt

This document requests IANA registration of an Enumservice for XMPP,
the Extensible Messaging and Presence Protocol.  This Enumservice
specifically allows the use of 'xmpp' Uniform Resource Identifiers
(URIs) in the context of E.164 Number Mapping (ENUM).  [STANDARDS TRACK]

This document is a product of the Telephone Number Mapping
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...



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



From enum-bounces@ietf.org Tue Aug 07 20:38:21 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IIZXU-00082J-80; Tue, 07 Aug 2007 20:36:40 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IIZXS-000813-Nk; Tue, 07 Aug 2007 20:36:38 -0400
Received: from bosco.isi.edu ([128.9.168.207])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IIZXS-0005VY-9R; Tue, 07 Aug 2007 20:36:38 -0400
Received: by bosco.isi.edu (Postfix, from userid 70)
	id A6125DF44A; Tue,  7 Aug 2007 17:36:16 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20070808003616.A6125DF44A@bosco.isi.edu>
Date: Tue,  7 Aug 2007 17:36:16 -0700 (PDT)
X-Spam-Score: -15.0 (---------------)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: enum@ietf.org, rfc-editor@rfc-editor.org
Subject: [Enum] RFC 4969 on IANA Registration for vCard Enumservice
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


A new Request for Comments is now available in online RFC libraries.

        
        RFC 4969

        Title:      IANA Registration for vCard Enumservice 
        Author:     A. Mayrhofer
        Status:     Standards Track
        Date:       August 2007
        Mailbox:    alexander.mayrhofer@enum.at
        Pages:      7
        Characters: 14038
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-enum-vcard-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4969.txt

This memo registers the Enumservice "vCard" using the URI schemes
"http" and "https".  This Enumservice is to be used to refer from an
ENUM domain name to a vCard instance describing the user of the
respective E.164 number.

Information gathered from those vCards could be used before, during,
or after inbound or outbound communication takes place.  For example,
a callee might be presented with the name and association of the
caller before picking up the call.  [STANDARDS TRACK]

This document is a product of the Telephone Number Mapping
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...



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



From enum-bounces@ietf.org Wed Aug 08 08:16:50 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IIkRH-0002f9-OD; Wed, 08 Aug 2007 08:14:59 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IIkRG-0002bD-1n
	for enum@ietf.org; Wed, 08 Aug 2007 08:14:58 -0400
Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIkRF-00059v-GN
	for enum@ietf.org; Wed, 08 Aug 2007 08:14:57 -0400
Received: from [10.10.0.105] (nat.labs.nic.at [::ffff:83.136.33.3])
	(AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
	by pahula with esmtp; Wed, 08 Aug 2007 14:14:52 +0200
	id 0006C0B1.46B9B3BC.000048BA
Message-ID: <46B9B31B.7050804@enum.at>
Date: Wed, 08 Aug 2007 14:12:11 +0200
From: Alexander Mayrhofer <alexander.mayrhofer@enum.at>
Organization: enum.at GmbH
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "'enum@ietf.org'" <enum@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Subject: [Enum] NITS on draft-ietf-enum-combined...
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


I've performed another NITS review on the "combined" draft - here are my
(editorial) comments - they can probably be fixed together with other
comments from the publication process:

- Section 5: Maybe it would make sense to explicitely state that for country
code 1, the POSITION is 1, because i was slightly confused by that sentence
about the NANP (it's in the algorithm anyway, but i think it would be good,
though)

- I'd like to see "ITU-T" expanded in the doc somewhere

- Section 6: First sentence contains a redundant 'the': "the the".

- Section 7: There is a redundant "." behind the DNAME reference


that's all

--alex


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



From enum-bounces@ietf.org Wed Aug 08 08:44:40 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IIksH-0007OG-0K; Wed, 08 Aug 2007 08:42:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IIksF-0007O9-Ot
	for enum@ietf.org; Wed, 08 Aug 2007 08:42:51 -0400
Received: from [203.187.132.25] (helo=tapal.aricent.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIksD-00072J-Mq
	for enum@ietf.org; Wed, 08 Aug 2007 08:42:51 -0400
Received: from tapal.aricent.com (localhost [127.0.0.1])
	by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l78CbCQw004192
	for <enum@ietf.org>; Wed, 8 Aug 2007 18:07:12 +0530
Received: from pragati.bgh.aricent.com (pragati.bgh.aricent.com 
	[10.203.193.22])by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id 
	l78CbBbS004189for <enum@ietf.org>; Wed, 8 Aug 2007 18:07:11 +0530
To: enum@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
Message-ID: <OFCAED332E.91650383-ON65257331.0044B833-65257331.0045D7EC@flextronicssoftware.com>
From: vadivel.subramaniam@aricent.com
Date: Wed, 8 Aug 2007 18:12:44 +0530
X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5.5|November 
	30, 2005) at08/08/2007 06:06:34 PM,Serialize complete at 08/08/2007 
	06:06:34 PM
X-imss-version: 2.047
X-imss-result: Passed
X-imss-scanInfo: M:B L:N SM:2
X-imss-tmaseResult: TT:1 TS:-18.3261 TC:1F TRN:49 TV:3.6.1039(15348.002)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.0000 0.0000)
X-Spam-Score: 2.9 (++)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Cc: venkat.reddy@aricent.com
Subject: [Enum] Query regarding NAPTR for resolving transport
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0048456301=="
Errors-To: enum-bounces@ietf.org

This is a multipart message in MIME format.
--===============0048456301==
Content-Type: multipart/alternative;
	boundary="=_alternative 0045D7EB65257331_="

This is a multipart message in MIME format.
--=_alternative 0045D7EB65257331_=
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: base64

SGkgQWxsLA0KDQpJIGhhdmUgYSBxdWVyeSByZWdhcmRpbmcgdGhlIHJlZ3VsYXIgZXhwcmVzc2lv
biBwYXR0ZXJucyB3aGljaCBhcmUgcGFydCBvZiANCnRoZSBOQVBUUiByZWNvcmRzLg0KDQpGb3Ig
RW51bSwgd2UgaGF2ZSAgICFwYXR0ZXJuIUFPUiEuICAgVGhlIG9yaWdpbmFsIGRvbWFpbiBpcyBy
ZXBsYWNlZCBieSANCkFPUiBjb21wYXJpbmcgdGhlIHBhdHRlcm4uIE1vc3QgY2FzZXMgcGF0dGVy
biBpcyAhXi4qJCFzaXA6dXNlckBkb21haW4hDQpTbyB0aGUgZnVsbCB1cmkgaXMgcmV0dXJuZWQg
YWZ0ZXIgcmVnIGV4cCBtYXRjaGluZy4NCg0KU2ltaWxhcmx5LCBGb3IgTkFQVFIgcmVjb3JkcyB0
byByZXNvbHZlIHRyYW5zcG9ydCwgSSBhbSByZWZlcnJpbmcgUkZDIDI5MTUgDQphbmQgdGhlcmUg
aXMgYW4gZXhhbXBsZSBnaXZlbi4NCg0Kc2lwOnVzZXJAZmFrZS5nYXRlY2guZWR1DQoNCmFuZCB0
aGUgcmVndWxhciBleHByZXNzaW9uIGlzICBzaXA6LitAKFteLl0rLikoLiopJC9cMi9pICAgICAg
ICAtPiBzdGF0ZXMgDQpJIHNob3VsZCB0YWtlIHRoZSBzZWNvbmQgc3Vic3RyaW5nIGZvciB0aGUg
ZnVydGhlciBOQVBUUiBsb29rdXAuIEluIHRoaXMgDQpjYXNlLCBpIGhhdmUgdG8gcXVlcnkgZm9y
IGdhdGVjaC5lZHUgYW5kIGdldCB0aGUgbGlzdCBvZiByZWNvcmRzLiAgVGhpcyANCndpbGwgY29u
dGludWUgdGlsbCBpIGdldCBhIHRlcm1pbmFsIHJlY29yZCBvZiB0eXBlICdzJyBvciAnYScuDQoN
Ck15IHF1ZXJpZXMsDQoNCjEuIElzIGl0IHRoZSBvbmx5IHBhdHRlcm4gYXBwbGljYWJsZSBmb3Ig
TkFQVFIgcmVjb3JkcyB3aGlsZSByZXNvbHZpbmcgDQp0cmFuc3BvcnQ/IGkuZS4gdGhlIG91dHB1
dCBvZiB0aGUgcmVnIGV4cCBpcyBhbHdheXMgdGhlIHN1YmRvbWFpbiB0byBxdWVyeSANCmZvciBO
QVBUUiBsb29rdXAuIA0KMi4gSXMgaXQgdmFsaWQgdG8gcHJvdmlkZSByZWd1bGFyIGV4cHJlc3Np
b24gbGlrZSByZXBsYWNlICJnYXRlY2giIHdpdGggDQoiZXhhbXBsZSIuICBUaGVuIGFzayB0aGUg
YXBwbGljYXRpb24gdG8gcXVlcnkgZm9yIGZha2UuZXhhbXBsZS5lZHUuDQoNClBsZWFzZSBwb3N0
IHlvdXIgcmVwbGllcy4NCg0KVGhhbmtzIGluIGFkdmFuY2UuDQoNCnJlZ2FyZHMNClZhZGl2ZWwu
DQoNCioqKioqKioqKioqKioqKioqKioqKioqICBBcmljZW50LVByaXZhdGUgICAqKioqKioqKioq
KioqKioqKioqKioqKg0KIkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0
byBBcmljZW50IGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRp
dmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2Vk
IG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRl
ZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVu
ZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ug
bm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50
ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpw
cm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRo
ZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJp
bGl0eSBmb3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZv
cm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2
aXJ1cy4iCg==
--=_alternative 0045D7EB65257331_=
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFsbCw8L2ZvbnQ+DQo8YnI+
DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSBhIHF1ZXJ5IHJlZ2Fy
ZGluZyB0aGUgcmVndWxhcg0KZXhwcmVzc2lvbiBwYXR0ZXJucyB3aGljaCBhcmUgcGFydCBvZiB0
aGUgTkFQVFIgcmVjb3Jkcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh
bnMtc2VyaWYiPkZvciBFbnVtLCB3ZSBoYXZlICZuYnNwOyAhcGF0dGVybiFBT1IhLg0KJm5ic3A7
IFRoZSBvcmlnaW5hbCBkb21haW4gaXMgcmVwbGFjZWQgYnkgQU9SIGNvbXBhcmluZyB0aGUgcGF0
dGVybi4gTW9zdA0KY2FzZXMgcGF0dGVybiBpcyA8Yj4hXi4qJCFzaXA6dXNlckBkb21haW4hPC9i
PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U28gdGhlIGZ1bGwg
dXJpIGlzIHJldHVybmVkIGFmdGVyIHJlZw0KZXhwIG1hdGNoaW5nLjwvZm9udD4NCjxicj4NCjxi
cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U2ltaWxhcmx5LCBGb3IgTkFQVFIgcmVj
b3JkcyB0byByZXNvbHZlDQp0cmFuc3BvcnQsIEkgYW0gcmVmZXJyaW5nIFJGQyAyOTE1IGFuZCB0
aGVyZSBpcyBhbiBleGFtcGxlIGdpdmVuLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg
ZmFjZT0ic2Fucy1zZXJpZiI+PGI+c2lwOnVzZXJAZmFrZS5nYXRlY2guZWR1PC9iPjwvZm9udD4N
Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YW5kIHRoZSByZWd1bGFy
IGV4cHJlc3Npb24gaXMgPGI+Jm5ic3A7c2lwOi4rQChbXi5dKy4pKC4qKSQvXDIvaQ0KPC9iPiZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0mZ3Q7IHN0YXRlcyBJIHNob3VsZCB0YWtlIHRoZSBz
ZWNvbmQgc3Vic3RyaW5nDQpmb3IgdGhlIGZ1cnRoZXIgTkFQVFIgbG9va3VwLiBJbiB0aGlzIGNh
c2UsIGkgaGF2ZSB0byBxdWVyeSBmb3IgZ2F0ZWNoLmVkdQ0KYW5kIGdldCB0aGUgbGlzdCBvZiBy
ZWNvcmRzLiAmbmJzcDtUaGlzIHdpbGwgY29udGludWUgdGlsbCBpIGdldCBhIHRlcm1pbmFsDQpy
ZWNvcmQgb2YgdHlwZSAncycgb3IgJ2EnLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg
ZmFjZT0ic2Fucy1zZXJpZiI+TXkgcXVlcmllcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6
ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjEuIElzIGl0IHRoZSBvbmx5IHBhdHRlcm4gYXBwbGljYWJs
ZQ0KZm9yIE5BUFRSIHJlY29yZHMgd2hpbGUgcmVzb2x2aW5nIHRyYW5zcG9ydD8gaS5lLiB0aGUg
b3V0cHV0IG9mIHRoZSByZWcNCmV4cCBpcyBhbHdheXMgdGhlIHN1YmRvbWFpbiB0byBxdWVyeSBm
b3IgTkFQVFIgbG9va3VwLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy
aWYiPjIuIElzIGl0IHZhbGlkIHRvIHByb3ZpZGUgcmVndWxhciBleHByZXNzaW9uDQpsaWtlIDxi
PnJlcGxhY2UgJnF1b3Q7Z2F0ZWNoJnF1b3Q7IDwvYj53aXRoPGI+ICZxdW90O2V4YW1wbGUmcXVv
dDs8L2I+Lg0KJm5ic3A7VGhlbiBhc2sgdGhlIGFwcGxpY2F0aW9uIHRvIHF1ZXJ5IGZvciA8Yj5m
YWtlLmV4YW1wbGUuZWR1LjwvYj48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9
InNhbnMtc2VyaWYiPlBsZWFzZSBwb3N0IHlvdXIgcmVwbGllcy48L2ZvbnQ+DQo8YnI+DQo8YnI+
PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBpbiBhZHZhbmNlLjwvZm9udD4N
Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+cmVnYXJkczwvZm9udD4N
Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VmFkaXZlbC48YnI+DQo8YnI+DQoq
KioqKioqKioqKioqKioqKioqKioqKiAmbmJzcDtBcmljZW50LVByaXZhdGUgJm5ic3A7ICoqKioq
KioqKioqKioqKioqKioqKioqPC9mb250Pg0KPHRhYmxlPjx0cj48dGQgYmdjb2xvcj0jZmZmZmZm
Pjxmb250IGNvbG9yPSMwMDAwMDA+PHByZT4iRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHBy
b3ByaWV0YXJ5IHRvIEFyaWNlbnQgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv
ZiAKdGhlIGluZGl2aWR1YWwgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIEl0IG1heSBjb250YWlu
IHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZCBzaG91bGQgbm90IGJl
IApjaXJjdWxhdGVkIG9yIHVzZWQgZm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4gZm9yIHdoYXQg
aXQgaXMgaW50ZW5kZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJv
ciwgCnBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUg
bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5b3UgYXJl
IHN0cmljdGx5CnByb2hpYml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0ZXJpbmcsIG9yIGRp
c2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gQXJpY2VudCBhY2NlcHRzIG5v
IHJlc3BvbnNpYmlsaXR5IGZvciAKbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ug
b2YgdGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRh
bWFnZSBmcm9tIHZpcnVzLiIKPC9wcmU+PC9mb250PjwvdGQ+PC90cj48L3RhYmxlPg==
--=_alternative 0045D7EB65257331_=--


--===============0048456301==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0048456301==--




From enum-bounces@ietf.org Wed Aug 08 11:03:21 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IIn2Q-0004OF-T8; Wed, 08 Aug 2007 11:01:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IIn2O-0004L8-LH
	for enum@ietf.org; Wed, 08 Aug 2007 11:01:28 -0400
Received: from mail.songbird.com ([208.184.79.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIn2M-0002ad-QS
	for enum@ietf.org; Wed, 08 Aug 2007 11:01:28 -0400
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
	l78F11SB011273
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 8 Aug 2007 08:01:02 -0700
From: "Richard Shockey" <richard@shockey.us>
To: <vadivel.subramaniam@aricent.com>
References: <OFCAED332E.91650383-ON65257331.0044B833-65257331.0045D7EC@flextronicssoftware.com>
In-Reply-To: <OFCAED332E.91650383-ON65257331.0044B833-65257331.0045D7EC@flextronicssoftware.com>
Subject: RE: [Enum] Query regarding NAPTR for resolving transport
Date: Wed, 8 Aug 2007 11:00:53 -0400
Message-ID: <002201c7d9cc$ebabf760$c303e620$@us>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcfZuZxucSmq6PBbQwKki2rL66kPOgAExL1A
Content-Language: en-us
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4515df9441674711565101d9d5c4f63f
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1332911726=="
Errors-To: enum-bounces@ietf.org

This is a multipart message in MIME format.

--===============1332911726==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0023_01C7D9AB.649A7E70"
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0023_01C7D9AB.649A7E70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Some one from the WG will try help you  but you should remove the company
disclaimer from future postings to IETF lists.  It's a big NO NO.

 

From: vadivel.subramaniam@aricent.com
[mailto:vadivel.subramaniam@aricent.com] 
Sent: Wednesday, August 08, 2007 8:43 AM
To: enum@ietf.org
Cc: venkat.reddy@aricent.com
Subject: [Enum] Query regarding NAPTR for resolving transport

 


Hi All, 

I have a query regarding the regular expression patterns which are part of
the NAPTR records. 

For Enum, we have   !pattern!AOR!.   The original domain is replaced by AOR
comparing the pattern. Most cases pattern is !^.*$!sip:user@domain! 
So the full uri is returned after reg exp matching. 

Similarly, For NAPTR records to resolve transport, I am referring RFC 2915
and there is an example given. 

sip:user@fake.gatech.edu 

and the regular expression is  sip:.+@([^.]+.)(.*)$/\2/i        -> states I
should take the second substring for the further NAPTR lookup. In this case,
i have to query for gatech.edu and get the list of records.  This will
continue till i get a terminal record of type 's' or 'a'. 

My queries, 

1. Is it the only pattern applicable for NAPTR records while resolving
transport? i.e. the output of the reg exp is always the subdomain to query
for NAPTR lookup. 
2. Is it valid to provide regular expression like replace "gatech" with
"example".  Then ask the application to query for fake.example.edu. 

Please post your replies. 

Thanks in advance. 

regards 
Vadivel.

***********************  Aricent-Private   *********************** 


"DISCLAIMER: This message is proprietary to Aricent and is intended solely
for the use of 
the individual to whom it is addressed. It may contain privileged or
confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If
you have received this message in error, 
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this
message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this
email including damage from virus."

 


------=_NextPart_000_0023_01C7D9AB.649A7E70
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Some one from the WG will try help you &nbsp;but you =
should remove
the company disclaimer from future postings to IETF lists.&nbsp; =
It&#8217;s a big NO NO.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal style=3D'margin-left:.5in'><b><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>From:</span></b><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> vadivel.subramaniam@aricent.com
[mailto:vadivel.subramaniam@aricent.com] <br>
<b>Sent:</b> Wednesday, August 08, 2007 8:43 AM<br>
<b>To:</b> enum@ietf.org<br>
<b>Cc:</b> venkat.reddy@aricent.com<br>
<b>Subject:</b> [Enum] Query regarding NAPTR for resolving =
transport<o:p></o:p></span></p>

</div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Hi =
All,</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I have =
a query
regarding the regular expression patterns which are part of the NAPTR =
records.</span>
<br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>For =
Enum, we
have &nbsp; !pattern!AOR!. &nbsp; The original domain is replaced by AOR
comparing the pattern. Most cases pattern is =
<b>!^.*$!sip:user@domain!</b></span>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>So the =
full uri
is returned after reg exp matching.</span> <br>
<br>
<span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Similarly, =
For
NAPTR records to resolve transport, I am referring RFC 2915 and there is =
an
example given.</span> <br>
<br>
<b><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>sip:user@fake=
.gatech.edu</span></b>
<br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>and =
the regular
expression is <b>&nbsp;sip:.+@([^.]+.)(.*)$/\2/i </b>&nbsp; &nbsp; =
&nbsp;
&nbsp;-&gt; states I should take the second substring for the further =
NAPTR
lookup. In this case, i have to query for gatech.edu and get the list of
records. &nbsp;This will continue till i get a terminal record of type =
's' or
'a'.</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>My =
queries,</span>
<br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>1. Is =
it the
only pattern applicable for NAPTR records while resolving transport? =
i.e. the
output of the reg exp is always the subdomain to query for NAPTR lookup. =
</span><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>2. Is =
it valid
to provide regular expression like <b>replace &quot;gatech&quot; =
</b>with<b>
&quot;example&quot;</b>. &nbsp;Then ask the application to query for =
<b>fake.example.edu.</b></span>
<br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Please =
post
your replies.</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Thanks =
in
advance.</span> <br>
<br>
<span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>regards</span=
> <br>
<span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Vadivel.<br>
<br>
*********************** &nbsp;Aricent-Private &nbsp; =
***********************</span>
<o:p></o:p></p>

<table class=3DMsoNormalTable border=3D0 cellspacing=3D3 cellpadding=3D0 =
width=3D788
 style=3D'width:472.5pt;margin-left:.5in'>
 <tr>
  <td style=3D'background:white;padding:.75pt .75pt .75pt =
.75pt'><pre><span
  style=3D'color:black'>&quot;DISCLAIMER: This message is proprietary to =
Aricent and is intended solely for the use of =
<o:p></o:p></span></pre><pre><span
  style=3D'color:black'>the individual to whom it is addressed. It may =
contain privileged or confidential information and should not be =
<o:p></o:p></span></pre><pre><span
  style=3D'color:black'>circulated or used for any purpose other than =
for what it is intended. If you have received this message in error, =
<o:p></o:p></span></pre><pre><span
  style=3D'color:black'>please notify the originator immediately. If you =
are not the intended recipient, you are notified that you are =
strictly<o:p></o:p></span></pre><pre><span
  style=3D'color:black'>prohibited from using, copying, altering, or =
disclosing the contents of this message. Aricent accepts no =
responsibility for <o:p></o:p></span></pre><pre><span
  style=3D'color:black'>loss or damage arising from the use of the =
information transmitted by this email including damage from =
virus.&quot;<o:p></o:p></span></pre></td>
 </tr>
</table>

<p class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0023_01C7D9AB.649A7E70--



--===============1332911726==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1332911726==--





From enum-bounces@ietf.org Wed Aug 08 11:56:00 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IInrN-0006EV-3M; Wed, 08 Aug 2007 11:54:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IInrL-0006AJ-CJ
	for enum@ietf.org; Wed, 08 Aug 2007 11:54:07 -0400
Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IInrJ-0003h5-OC
	for enum@ietf.org; Wed, 08 Aug 2007 11:54:07 -0400
Received: from [10.10.0.105] (nat.labs.nic.at [::ffff:83.136.33.3])
	(AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
	by pahula with esmtp; Wed, 08 Aug 2007 17:54:02 +0200
	id 0006C0B8.46B9E71A.00006F09
Message-ID: <46B9E678.5020207@enum.at>
Date: Wed, 08 Aug 2007 17:51:20 +0200
From: Alexander Mayrhofer <alexander.mayrhofer@enum.at>
Organization: enum.at GmbH
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "'enum@ietf.org'" <enum@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Subject: [Enum] NITS review of draft-ietf-enum-unused
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


Hi,

i've done a review of draft-ietf-enum-unused-02 - my comments and
suggestions as follows:

- editorial: the automated idnits checker complains about the text of the
Terminology section, probably because it's missing the "RFC 2119" snippet
(reference is OK, though)

- editorial: Please expand "ENUM" in the Introduction, the expansion "du
jour" seems to be "E.164 Number Mapping"...

- editorial: more unexplained acronyms include "NAPTR", "URI", "DNSSEC"
(unless i overlooked them).

- content: Section 4 proposes to use that Enumservice with "this 'number
unused' state", however, there is no definition of this state. I think it
would be good to add text in section 3 which defines to which cases "number
unused" refers, PLUS it would be good to state somewhere that this
Enumservice is not to be used for numbers in any other status.

(Note: Is there a sensible case in which one would mix this Enumservice with
other Enumservices in a single RRSET? Maybe there could be some text about
this, although i don't want to go down the hole of "unused, but only for
certain services" :)

- content: It looks like Section 4 proposes some standardization effort on a
national basis in the last sentence. I know that the outcome from the URI is
not to be used for the actual call, but it sounds as if i had to wait for a
national body to define something before i can actually use it... Not sure
what can be done about this, maybe saying something like "the contents of
the data URI SHOULD provide additional information about the reason for the
existance of this record" (??).

- nit: Please use example phone number ranges in Section 6. A list of such
ranges can be found on http://www.ietf.org/ID-Checklist.html#anchor6 (scroll
down to "phone numbers"). For no particular reason, i personally prefer to
use the Nottingham area code when dealing with ENUM :)


that's all

--alex

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



From enum-bounces@ietf.org Thu Aug 09 14:17:04 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IJCXS-0005KC-6V; Thu, 09 Aug 2007 14:15:14 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IJCXH-0004yu-Cc; Thu, 09 Aug 2007 14:15:03 -0400
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IJCXG-0002Ux-Vk; Thu, 09 Aug 2007 14:15:03 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A25ED175D0;
	Thu,  9 Aug 2007 18:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IJCXG-00048E-4t; Thu, 09 Aug 2007 14:15:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1IJCXG-00048E-4t@stiedprstage1.ietf.org>
Date: Thu, 09 Aug 2007 14:15:02 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: enum@ietf.org
Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-token-04.txt 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title		: ENUM Validation Token Format Definition
	Author(s)	: O. Lendl
	Filename	: draft-ietf-enum-validation-token-04.txt
	Pages		: 17
	Date		: 2007-8-9
	
An ENUM domain name is tightly coupled with the underlying E.164
   number.  The process of verifying whether the Registrant of an ENUM
   domain name is identical to the Assignee of the corresponding E.164
   number is commonly called "validation".  This document describes an
   signed XML data format -- the Validation Token -- with which
   Validation Entities can convey successful completion of a validation
   procedure in a secure fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-token-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-enum-validation-token-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-enum-validation-token-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-8-9134158.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-enum-validation-token-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-enum-validation-token-04.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-8-9134158.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From enum-bounces@ietf.org Thu Aug 09 14:17:26 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IJCXt-0005yo-Ob; Thu, 09 Aug 2007 14:15:41 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IJCXl-0005rh-FP; Thu, 09 Aug 2007 14:15:33 -0400
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IJCXl-0002Wn-14; Thu, 09 Aug 2007 14:15:33 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AFC52175D7;
	Thu,  9 Aug 2007 18:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IJCXG-00048L-6D; Thu, 09 Aug 2007 14:15:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1IJCXG-00048L-6D@stiedprstage1.ietf.org>
Date: Thu, 09 Aug 2007 14:15:02 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: enum@ietf.org
Subject: [Enum] I-D ACTION:draft-ietf-enum-combined-07.txt 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title		: Combined User and Infrastructure ENUM in the e164.arpa tree
	Author(s)	: M. Haberler, et al.
	Filename	: draft-ietf-enum-combined-07.txt
	Pages		: 11
	Date		: 2007-8-9
	
This memo defines an interim solution for Infrastructure ENUM to
   allow a combined User and Infrastructure ENUM implementation in
   e164.arpa as a national choice until the long-term solution is
   approved.  This interim solution will be deprecated after approval of
   the long-term solution.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-combined-07.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-combined-07.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-combined-07.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: <2007-8-9134633.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-enum-combined-07.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-enum-combined-07.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-8-9134633.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From enum-bounces@ietf.org Sun Aug 12 14:32:53 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IKICS-0005R7-KB; Sun, 12 Aug 2007 14:30:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IKICR-0005R2-SB
	for enum@ietf.org; Sun, 12 Aug 2007 14:30:03 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKICQ-0001fg-Ft
	for enum@ietf.org; Sun, 12 Aug 2007 14:30:03 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-5.cisco.com with ESMTP; 12 Aug 2007 11:30:01 -0700
X-IronPort-AV: i="4.19,251,1183359600"; 
	d="scan'208"; a="170588221:sNHT49419639"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7CIU13a028501; 
	Sun, 12 Aug 2007 11:30:01 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l7CIU0gB017246;
	Sun, 12 Aug 2007 18:30:00 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 12 Aug 2007 11:30:00 -0700
Received: from [192.168.1.3] ([10.21.116.53]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 12 Aug 2007 11:30:00 -0700
In-Reply-To: <03b001c7c956$622c0150$268403f0$@us>
References: <03b001c7c956$622c0150$268403f0$@us>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <028AC098-4CB2-4864-9CA1-8F016D632B13@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Subject: Re: GO to WGLC ?FW: [Enum] I-D ACTION:draft-ietf-enum-iax-03.txt
Date: Sun, 12 Aug 2007 11:28:49 -0700
To: Richard Shockey <richard@shockey.us>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 12 Aug 2007 18:30:00.0227 (UTC)
	FILETIME=[CAA26730:01C7DD0E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3368; t=1186943401;
	x=1187807401; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20Re=3A=20GO=20to=20WGLC=20?FW=3A=20[Enum]=20I-D=20ACTION=3Adra
	ft-ietf-enum-iax-03.txt |Sender:=20;
	bh=n0LNuS1BQRgGWtYzAFWYaEVkPFZFUBREnEUZCOreNGI=;
	b=MKNz1/DnOcTz1zqNaHNnUEbaheUxaOUHKb68JDtOeknGeL1Xw6hyLVY9Dfs45v9qNRjLF1mR
	qA+ackdyfktR+mbmRLa1clp+nji3XTBCmUy0SCabjxSHt/JpcCEEi0NS;
Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: enum@ietf.org, 'Alexander Mayrhofer' <alexander.mayrhofer@nic.at>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org


The iax2 scheme has received some criticism for embedding version  
negotiation in the scheme name - I don't know if this is will result  
in changes or not, I'm just pointing out it was an issue raised that  
might impact this work. You might want to wait until that was  
standardized before moving forward. Either way, this is going to  
block on draft-guy-iax - it is unclear to me if draft-guy-ias is  
close to being published published or not.


On Jul 18, 2007, at 9:11 AM, Richard Shockey wrote:

> I looked at this and it looks "good to go" are there any other  
> comments on
> this ?
>
> I think a NITS review is in order. I see only one contingent  
> dependency
> which is in an advanced state.
>
>
>
> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Friday, July 13, 2007 2:15 PM
> To: i-d-announce@ietf.org
> Cc: enum@ietf.org
> Subject: [Enum] I-D ACTION:draft-ietf-enum-iax-03.txt
>
> 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 IAX Enumservice
> 	Author(s)	: E. Guy
> 	Filename	: draft-ietf-enum-iax-03.txt
> 	Pages		: 9
> 	Date		: 2007-7-13
> 	
> This document registers the IAX2 (Inter-Asterisk eXchange Version 2)
>    Enumservice using the URI scheme 'iax2:' as per the IANA  
> registration
>    process defined in the ENUM specification RFC3761.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-enum-iax-03.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-iax-03.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-iax-03.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@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum

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



From enum-bounces@ietf.org Tue Aug 21 09:43:15 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1INTyw-0003Bj-FS; Tue, 21 Aug 2007 09:41:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1INTyv-0003Be-Qf
	for enum@ietf.org; Tue, 21 Aug 2007 09:41:17 -0400
Received: from web8505.mail.in.yahoo.com ([202.43.219.167])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1INTyu-0001jh-4a
	for enum@ietf.org; Tue, 21 Aug 2007 09:41:17 -0400
Received: (qmail 51326 invoked by uid 60001); 21 Aug 2007 13:41:13 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in;
	h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
	b=DhJlPe/NIEbWe2sqGyrvNKdSushQvU4LoUEg8/XZplPI80+30Tj1ENjmLQJazGg9Qn+FSTPLornGiu8lYDH6HGKpl9VRNa2ugXXeo6A2vV5TLLIEea1fEmog3jL20meOCFo+1vU/Fg/uWc2ih1Vke9Blz8xQsPPjl7M+p01arR0=;
X-YMail-OSG: kfmSD2YVM1mFe3pStqqxpGp8Q.lHbvdkWUbznW2F7LxmolSNPv2oGxZVGo.TYVg6AIWMnaLON6GK2F5WYmCHY5UTweyoxaXT7sFWW0Xv_QWiOB6bvuzPH5rEHA--
Received: from [203.187.132.49] by web8505.mail.in.yahoo.com via HTTP;
	Tue, 21 Aug 2007 14:41:13 BST
Date: Tue, 21 Aug 2007 14:41:13 +0100 (BST)
From: Vadivel Subramaniam <csvadivel@yahoo.co.in>
To: enum@ietf.org
MIME-Version: 1.0
Message-ID: <849270.50225.qm@web8505.mail.in.yahoo.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: venkat.reddy@aricent.com, csvadivel@yahoo.co.in
Subject: [Enum] NAPTR record types for resolving transport
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0074921520=="
Errors-To: enum-bounces@ietf.org

--===============0074921520==
Content-Type: multipart/alternative; boundary="0-2085126056-1187703673=:50225"
Content-Transfer-Encoding: 8bit

--0-2085126056-1187703673=:50225
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,
   
  I am writing a client to resolve the transport from a SIP uri.  The types of NAPTR records which can be returned are with flags "S" or "A" or "U".
   
  I can chose the transport by matching the domain name in the original SIP uri with the replacement field values of "S" or "A" type records. 
   
  The records of type 'U' will not have a replacement field value. They will only have regexp.
   
  Is it valid to have "U" records while resolving transport for SIP uri's? 
   
  Please post your replies.
   
  thanks,
  Vadivel.
   
  
 

       
---------------------------------
 Yahoo! Answers - Get better answers from someone who knows. Tryit now.
--0-2085126056-1187703673=:50225
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<div>Hi,</div>  <div>&nbsp;</div>  <div>I am writing a client to resolve the transport from&nbsp;a SIP uri.&nbsp; The types of NAPTR records which can be returned are with flags "S" or "A" or "U".</div>  <div>&nbsp;</div>  <div>I can chose the transport by matching the domain name in the original SIP uri with the replacement field values of "S" or "A" type records. </div>  <div>&nbsp;</div>  <div>The records of type 'U' will not have&nbsp;a replacement field value. They will&nbsp;only have&nbsp;regexp.</div>  <div>&nbsp;</div>  <div>Is it valid to have&nbsp;"U" records while resolving transport for SIP uri's? </div>  <div>&nbsp;</div>  <div>Please post your replies.</div>  <div>&nbsp;</div>  <div>thanks,</div>  <div>Vadivel.</div>  <div>&nbsp;</div>  <div><BR>&nbsp;</div><p>&#32;
      <hr size=1> 
Yahoo! Answers - Get better answers from someone who knows. <a
href="http://uk.answers.yahoo.com/;_ylc=X3oDMTEydmViNG02BF9TAzIxMTQ3MTcxOTAEc2VjA21haWwEc2xrA3RhZ2xpbmU">Try
it now</a>.
--0-2085126056-1187703673=:50225--


--===============0074921520==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0074921520==--




From enum-bounces@ietf.org Tue Aug 21 09:56:28 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1INUBv-0001I3-2Y; Tue, 21 Aug 2007 09:54:43 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1INUBt-00012Y-J8; Tue, 21 Aug 2007 09:54:41 -0400
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1INUBt-0006OM-AF; Tue, 21 Aug 2007 09:54:41 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 335272AC88;
	Tue, 21 Aug 2007 13:54:41 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1INUBs-0003Gf-Vg; Tue, 21 Aug 2007 09:54:40 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1INUBs-0003Gf-Vg@stiedprstage1.ietf.org>
Date: Tue, 21 Aug 2007 09:54:40 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: enum mailing list <enum@ietf.org>, enum chair <enum-chairs@tools.ietf.org>,
	Internet Architecture Board <iab@iab.org>,
	RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Enum] Protocol Action: 'A Telephone Number Mapping (ENUM) 
 Service Registration for Instant Messaging (IM) Services' to 
 Proposed Standard 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

The IESG has approved the following document:

- 'A Telephone Number Mapping (ENUM) Service Registration for Instant 
   Messaging (IM) Services '
   <draft-ietf-enum-im-service-03.txt> 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-im-service-03.txt

Technical Summary
 
This document registers a Telephone Number Mapping (ENUM) service for
Instant Messaging (IM).  Specifically, this document focuses on
provisioning 'im:' URIs in ENUM.
 
Working Group Summary
 
The document represents another mapping of E.164 number to an application,
in this case instant messaging services. This service might assist global
operators in integrating IM and SMS services transparently.
 
Protocol Quality
 
This document was reviewed for the IESG by Jon Peterson.


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



From enum-bounces@ietf.org Tue Aug 21 10:25:06 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1INUdc-0006qE-Tt; Tue, 21 Aug 2007 10:23:20 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1INUdb-0006ot-Ot
	for enum@ietf.org; Tue, 21 Aug 2007 10:23:19 -0400
Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INUdb-0007OG-5L
	for enum@ietf.org; Tue, 21 Aug 2007 10:23:19 -0400
Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian))
	id 1INUdW-0007m6-00; Tue, 21 Aug 2007 16:23:14 +0200
Date: Tue, 21 Aug 2007 16:23:14 +0200
From: Otmar Lendl <lendl@nic.at>
To: Vadivel Subramaniam <csvadivel@yahoo.co.in>
Subject: Re: [Enum] NAPTR record types for resolving transport
Message-ID: <20070821142314.GA29879@nic.at>
Mail-Followup-To: Otmar Lendl <lendl@nic.at>,
	Vadivel Subramaniam <csvadivel@yahoo.co.in>, enum@ietf.org,
	venkat.reddy@aricent.com
References: <849270.50225.qm@web8505.mail.in.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <849270.50225.qm@web8505.mail.in.yahoo.com>
User-Agent: Mutt/1.5.9i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: enum@ietf.org, venkat.reddy@aricent.com
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On 2007/08/21 15:08, Vadivel Subramaniam <csvadivel@yahoo.co.in> wrote:
> Hi,
>    
>   I am writing a client to resolve the transport from a SIP uri. The
> types of NAPTR records which can be returned are with flags "S" or "A"
> or "U".

Are you sure you're not mixing up NAPTRs as used in RFC 3263 with
the NAPTRs used for ENUM?

These are two completely separate use-cases of the NAPTR record.

/ol
-- 
/ Otmar Lendl <lendl@nic.at>, 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://www1.ietf.org/mailman/listinfo/enum



From enum-bounces@ietf.org Tue Aug 21 11:50:33 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1INVyF-0007Tx-9i; Tue, 21 Aug 2007 11:48:43 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1INVyE-0007Tp-1c
	for enum@ietf.org; Tue, 21 Aug 2007 11:48:42 -0400
Received: from web8512.mail.in.yahoo.com ([202.43.219.105])
	by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1INVyD-0002tX-2r
	for enum@ietf.org; Tue, 21 Aug 2007 11:48:41 -0400
Received: (qmail 14517 invoked by uid 60001); 21 Aug 2007 15:48:38 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in;
	h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
	b=yDRxpiPteEoKyw7RfQlgEEglj5ty79cRSafbNnG8VeNOHZBHoZa7zmT9Nt1EAf1LY6jyhZTYObdtuFV3kqQkfzCLDhTLiKzu0deQ4NEFj/Ip3jAxnLjKncWALOE/rPar9v56Aqxr54kzmda5FJA0zSpLpoIYDhy5ngtKMWB7irw=;
X-YMail-OSG: 5vAEDJQVM1mWaS.IJGxzs9_SfgkAPVfxhEsZyUOOptUV.UBJ0KWGsnTN1HrBXNFyKVeM67ZKSXFgfRuVu3YOf1iL4Wg_yxKn02Hy0yT7qvaqxgHXziDpMlup_KEpPQ--
Received: from [203.187.132.49] by web8512.mail.in.yahoo.com via HTTP;
	Tue, 21 Aug 2007 16:48:37 BST
Date: Tue, 21 Aug 2007 16:48:37 +0100 (BST)
From: Vadivel Subramaniam <csvadivel@yahoo.co.in>
Subject: Re: [Enum] NAPTR record types for resolving transport
To: Otmar Lendl <lendl@nic.at>
In-Reply-To: <20070821142314.GA29879@nic.at>
MIME-Version: 1.0
Message-ID: <229943.14506.qm@web8512.mail.in.yahoo.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: enum@ietf.org, venkat.reddy@aricent.com
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0515269116=="
Errors-To: enum-bounces@ietf.org

--===============0515269116==
Content-Type: multipart/alternative; boundary="0-613914917-1187711317=:14506"
Content-Transfer-Encoding: 8bit

--0-613914917-1187711317=:14506
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi Otmar,
   
  Resolving ENUM to SIP uri is a different application which we already have. That considers "U" records and returns the URI.
   
  This new application which I am developing now, will have to resolve only the transport based on the SIP uri. 
   
  My questions are
  1) Can 'U' records be returned as part of NAPTR lookup while resolving the transport?
   
  2) Whether "S" or "A" records are the only records expected from DNS while resolving transport using NAPTR lookup?
   
  thanks,
  Vadivel

Otmar Lendl <lendl@nic.at> wrote:
  On 2007/08/21 15:08, Vadivel Subramaniam wrote:
> Hi,
> 
> I am writing a client to resolve the transport from a SIP uri. The
> types of NAPTR records which can be returned are with flags "S" or "A"
> or "U".

Are you sure you're not mixing up NAPTRs as used in RFC 3263 with
the NAPTRs used for ENUM?

These are two completely separate use-cases of the NAPTR record.

/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://www1.ietf.org/mailman/listinfo/enum


       
---------------------------------
 Yahoo! Answers - Get better answers from someone who knows. Tryit now.
--0-613914917-1187711317=:14506
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<div>Hi Otmar,</div>  <div>&nbsp;</div>  <div>Resolving ENUM to SIP uri is a different application&nbsp;which we already have. That considers&nbsp;"U" records and returns the URI.</div>  <div>&nbsp;</div>  <div>This new application which I am developing now,&nbsp;will have to resolve only the transport based on the SIP uri.&nbsp;</div>  <div>&nbsp;</div>  <div>My&nbsp;questions&nbsp;are</div>  <div>1)&nbsp;Can 'U' records&nbsp;be returned as part of NAPTR lookup while resolving the transport?</div>  <div>&nbsp;</div>  <div>2)&nbsp;Whether&nbsp;"S" or "A" records are the&nbsp;only&nbsp;records expected from DNS&nbsp;while resolving transport using NAPTR lookup?</div>  <div>&nbsp;</div>  <div>thanks,</div>  <div>Vadivel<BR><BR><B><I>Otmar Lendl &lt;lendl@nic.at&gt;</I></B> wrote:</div>  <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">On 2007/08/21 15:08, Vadivel Subramaniam <CSVADIVEL@YAHOO.CO.IN>wrote:<BR>&gt; Hi,<BR>&gt;
 <BR>&gt; I am writing a client to resolve the transport from a SIP uri. The<BR>&gt; types of NAPTR records which can be returned are with flags "S" or "A"<BR>&gt; or "U".<BR><BR>Are you sure you're not mixing up NAPTRs as used in RFC 3263 with<BR>the NAPTRs used for ENUM?<BR><BR>These are two completely separate use-cases of the NAPTR record.<BR><BR>/ol<BR>-- <BR>/ Otmar Lendl <LENDL@NIC.AT>, T: <?XML:NAMESPACE PREFIX = SKYPE /><SKYPE:SPAN onmouseup="javascript:skype_tb_imgOnOff(this,1,'0',false,16,'');return skype_tb_stopEvents();" class=skype_tb_injection oncontextmenu="javascript:skype_tb_SwitchDrop(this,'0','sms=0');return skype_tb_stopEvents();" onmousedown="javascript:skype_tb_imgOnOff(this,2,'0',false,16,'');return skype_tb_stopEvents();" id=softomate_highlight_0 onmouseover="javascript:skype_tb_imgOnOff(this,1,'0',false,16,'');" title="Call this phone number in Austria with Skype: +431505641633" onclick="javascript:doRunCMD('call','0',null,0);return
 skype_tb_stopEvents();" onmouseout="javascript:skype_tb_imgOnOff(this,0,'0',false,16,'');" durex="414" context="+43 1 5056416 - 33"><SKYPE:SPAN class=skype_tb_imgA id=skype_tb_droppart_0 title="This is a Austria phone number. The country code cannot be changed." style="BACKGROUND-IMAGE: url(C:\DOCUME~1\VSUBRA~1\LOCALS~1\Temp\__SkypeIEToolbar_Cache\e70d95847a8f5723cfca6b3fd9946506\static\inactive_a.compat.stat.w16.gif)"><SKYPE:SPAN class=skype_tb_imgFlag id=skype_tb_img_f0 style="BACKGROUND-IMAGE: url(C:\DOCUME~1\VSUBRA~1\LOCALS~1\Temp\__SkypeIEToolbar_Cache\e70d95847a8f5723cfca6b3fd9946506\static\famfamfam/AT.gif)"></SKYPE:SPAN></SKYPE:SPAN><SKYPE:SPAN class=skype_tb_imgS_stat id=skype_tb_img_s0></SKYPE:SPAN><SKYPE:SPAN class=skype_tb_injectionIn id=skype_tb_text0><SKYPE:SPAN class=skype_tb_innerText id=skype_tb_innerText0>+43&nbsp;1&nbsp;5056416&nbsp;-&nbsp;33</SKYPE:SPAN></SKYPE:SPAN><SKYPE:SPAN class=skype_tb_imgR id=skype_tb_img_r0></SKYPE:SPAN></SKYPE:SPAN>, F: - 933
 \<BR>| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |<BR>\ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg /<BR><BR>_______________________________________________<BR>enum mailing list<BR>enum@ietf.org<BR>https://www1.ietf.org/mailman/listinfo/enum<BR></BLOCKQUOTE><BR><p>&#32;
      <hr size=1> 
Yahoo! Answers - Get better answers from someone who knows. <a
href="http://uk.answers.yahoo.com/;_ylc=X3oDMTEydmViNG02BF9TAzIxMTQ3MTcxOTAEc2VjA21haWwEc2xrA3RhZ2xpbmU">Try
it now</a>.
--0-613914917-1187711317=:14506--


--===============0515269116==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0515269116==--




From enum-bounces@ietf.org Tue Aug 21 11:51:48 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1INVzX-00087t-Uf; Tue, 21 Aug 2007 11:50:03 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1INVzW-00087n-PF
	for enum@ietf.org; Tue, 21 Aug 2007 11:50:02 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INVzW-0002w7-CT
	for enum@ietf.org; Tue, 21 Aug 2007 11:50:02 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-3.cisco.com with ESMTP; 21 Aug 2007 08:50:02 -0700
X-IronPort-AV: i="4.19,290,1183359600"; 
	d="scan'208"; a="515574585:sNHT46210906"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7LFo1o6004769; 
	Tue, 21 Aug 2007 08:50:01 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7LFnJFQ012507;
	Tue, 21 Aug 2007 15:49:57 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 21 Aug 2007 08:49:53 -0700
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 21 Aug 2007 08:49:52 -0700
In-Reply-To: <OFCAED332E.91650383-ON65257331.0044B833-65257331.0045D7EC@flextronicssoftware.com>
References: <OFCAED332E.91650383-ON65257331.0044B833-65257331.0045D7EC@flextronicssoftware.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5DB15BFB-86E0-4265-B932-AD149CC09E02@cisco.com>
Content-Transfer-Encoding: 7bit
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Subject: Re: [Enum] Query regarding NAPTR for resolving transport
Date: Tue, 21 Aug 2007 08:49:46 -0700
To: vadivel.subramaniam@aricent.com
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 21 Aug 2007 15:49:52.0742 (UTC)
	FILETIME=[E9D84860:01C7E40A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=691; t=1187711401;
	x=1188575401; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paf@cisco.com;
	z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20<paf@cisco.com>
	|Subject:=20Re=3A=20[Enum]=20Query=20regarding=20NAPTR=20for=20resolving=
	20transport |Sender:=20;
	bh=wp8d/jK8Uukex8iApp8xCcAjJQUNY6NRFge7oOiw3tM=;
	b=lHMl7WqS9V46MhJH6ws67myG4Kr74o2U945y/d117mSQMxCl4L4RtIrWkOEgWsLYLZLYRTAs
	huE+LAJr3us5g8HtuXDf1/v4UV3etZ7v+gXpYstr5TOwdBth8rxWa1ul;
Authentication-Results: sj-dkim-3; header.From=paf@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: enum@ietf.org, venkat.reddy@aricent.com
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On 8 aug 2007, at 05.42, vadivel.subramaniam@aricent.com wrote:

> 1. Is it the only pattern applicable for NAPTR records while resolving
> transport? i.e. the output of the reg exp is always the subdomain  
> to query
> for NAPTR lookup.

No, you can have any result of the regexp calculation. Do not take  
for granted the output is something special, or related to any of the  
domain names you already "have in your hand".

> 2. Is it valid to provide regular expression like replace "gatech"  
> with
> "example".  Then ask the application to query for fake.example.edu.

You can have anything you want in the regexp. Please provide a  
specific example.

    Patrik

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



From enum-bounces@ietf.org Tue Aug 21 12:02:30 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1INW9s-0002tv-5f; Tue, 21 Aug 2007 12:00:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1INW9q-0002l4-Ho
	for enum@ietf.org; Tue, 21 Aug 2007 12:00:42 -0400
Received: from fw-d-whp.denic.de ([81.91.160.27] helo=denic.de)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INW9p-00077n-34
	for enum@ietf.org; Tue, 21 Aug 2007 12:00:42 -0400
Received: by unknown.office.denic.de (Postfix, from userid 501)
	id ED54D5098FC; Tue, 21 Aug 2007 18:00:39 +0200 (CEST)
Date: Tue, 21 Aug 2007 18:00:39 +0200
From: Peter Koch <pk@DENIC.DE>
To: Vadivel Subramaniam <csvadivel@yahoo.co.in>
Subject: Re: [Enum] NAPTR record types for resolving transport
Message-ID: <20070821160039.GL11435@unknown.office.denic.de>
Mail-Followup-To: Vadivel Subramaniam <csvadivel@yahoo.co.in>,
	enum@ietf.org, venkat.reddy@aricent.com
References: <20070821142314.GA29879@nic.at>
	<229943.14506.qm@web8512.mail.in.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <229943.14506.qm@web8512.mail.in.yahoo.com>
User-Agent: Mutt/1.4.2.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: enum@ietf.org, venkat.reddy@aricent.com
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On Tue, Aug 21, 2007 at 04:48:37PM +0100, Vadivel Subramaniam wrote:

>   My questions are
>   1) Can 'U' records be returned as part of NAPTR lookup while resolving the transport?

the problem is that RFC 3263 refers to the NAPTR specification as of RFC 2915,
which, by default", defines flags "A", "S", and "U", leaving others to the
specific application.
RFC 3403 redefined NAPTR in the context of DDDS without giving any default
flags.  It also says that REGEXP and REPLACEMENT are mutually exclusive.

This question might be better asked in one of the SIP related fora or WGs,
so actual deployed uses can be taken into account.

>From a DNS perspective, methinks RFC 3263 needs a refresh.

-Peter

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



From enum-bounces@ietf.org Thu Aug 23 10:13:00 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IODOm-0003X2-Vg; Thu, 23 Aug 2007 10:11:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IODOl-0003Wo-SY; Thu, 23 Aug 2007 10:10:59 -0400
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IODOl-0006oU-KD; Thu, 23 Aug 2007 10:10:59 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 74A91327C7;
	Thu, 23 Aug 2007 14:10:59 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IODOl-0004pZ-CD; Thu, 23 Aug 2007 10:10:59 -0400
X-test-idtracker: no
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1IODOl-0004pZ-CD@stiedprstage1.ietf.org>
Date: Thu, 23 Aug 2007 10:10:59 -0400
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: enum@ietf.org
Subject: [Enum] Last Call: draft-ietf-enum-calendar-service (A Telephone
 Number 
 Mapping (ENUM) Service Registration for Internet Calendaring 
 Services) to Proposed Standard 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

The IESG has received a request from the Telephone Number Mapping WG 
(enum) to consider the following document:

- 'A Telephone Number Mapping (ENUM) Service Registration for Internet 
   Calendaring Services '
   <draft-ietf-enum-calendar-service-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2007-09-06. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-03.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14544&rfc_flag=0


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



From enum-bounces@ietf.org Thu Aug 23 10:39:00 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IODo6-0002mU-DK; Thu, 23 Aug 2007 10:37:10 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IODo5-0002mO-0l
	for enum@ietf.org; Thu, 23 Aug 2007 10:37:09 -0400
Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IODo4-0008Er-A3
	for enum@ietf.org; Thu, 23 Aug 2007 10:37:08 -0400
Received: from [10.10.0.128] (nat.labs.nic.at [::ffff:83.136.33.3])
	(AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
	by pahula with esmtp; Thu, 23 Aug 2007 16:37:05 +0200
	id 0006C0B4.46CD9B91.00001E4D
Message-ID: <46CD9ADC.9000006@enum.at>
Date: Thu, 23 Aug 2007 16:34:04 +0200
From: Alexander Mayrhofer <alexander.mayrhofer@enum.at>
Organization: enum.at GmbH
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Rohan Mahy <rohan@ekabal.com>, enum@ietf.org
References: <E1IODOl-0004pZ-CD@stiedprstage1.ietf.org>
In-Reply-To: <E1IODOl-0004pZ-CD@stiedprstage1.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: 
Subject: [Enum] Re: Last Call: draft-ietf-enum-calendar-service (A Telephone
 Number
 Mapping (ENUM) Service Registration for Internet Calendaring  Services)
 to Proposed Standard
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

The IESG wrote:
> The IESG has received a request from the Telephone Number Mapping WG 
> (enum) to consider the following document:
> 
> - 'A Telephone Number Mapping (ENUM) Service Registration for Internet 
>    Calendaring Services '
>    <draft-ietf-enum-calendar-service-03.txt> as a Proposed Standard

Hi,

(yes, i know that it's _very very_ late for this, and i hate to receive
similar comments on my documents... but - better late than never?)

Two things (i start with the non-issue..)

- I seem to have overlooked that the shortcut title of the document still
says "IM Enumservice", even though this is the calendar Enumservice, seems
to be a leftover from copying the other template.

Now the harder issue: Subtypes.

- In the light of the discussions around Enumservice classification in
Chicago, i examined the type/subtype combinations, and i feel a bit unease
about not using any subtypes for this Enumservice, because this Enumservice
covers two completely different calendaring protocols (iMIP and CalDAV). I
consider being "ical" and "application class" Enumservice, according what we
added to the enumservices guide in the recent revision.

A bit more about the subtyping decision:

Keep in mind that a client is not allowed to "look" at the URI scheme for
choosing a ENUM records, so it can only guess whether the record would be
for an iMIP or an CalDAV address when there is no subtype given. Only the
type and subtype must be used to choose a NAPTR from a set of records - so a
client would not be able to find out whether a NAPTR refers to a "iMIP" or
"CalDAV" resource..

That might well lead to problems when a client finds out that the "ical"
record it has just chosen lists a iMIP address, while the client only
supports CalDAV. According to RFC3761, it can't "go back" anymore, and try
the other "ical" record, even if that would have contained a CalDAV URI. So
the client would fail to contact the calendaring resource, even though it
_would_ have been able to contact it in case it had chosen the other record
("russian ENUM roulette", anybody?)

- A second concern might be that there _could_ be calendaring protocols that
use http/https URIs as well, but don't represent CalDAV resources (who
knows?). A client would have no chance in finding out which "http-using"
calendaring protocol the NAPTR addresses without contacting the actual
calendar service.

I'd suggest to change (yes, i know, 5 mins after 12) that Enumservice
registration to two distinct registrations, both with a subtype, like:

a) Name: "iCal"
   Type: "ical"
   Subtype: "caldav"
   URI schemes: "http", "https"

b) Name: "iCal"
   Type: "ical"
   Subtype: "imip"
   URI schemes: "mailto"

That would clarify to the client which calendaring protocol is in use, would
allow other potential calendaring protocols to use http/https as well, and
generally give me a better feeling about that Enumservice than the current
document does...

Comments?

(and, again, sorry for being late!)

---
Alex Mayrhofer
enum.at

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



From enum-bounces@ietf.org Thu Aug 23 13:08:08 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IOG8O-0002ev-30; Thu, 23 Aug 2007 13:06:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IOG8N-0002eq-Ik
	for enum@ietf.org; Thu, 23 Aug 2007 13:06:15 -0400
Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOG8M-0003O5-91
	for enum@ietf.org; Thu, 23 Aug 2007 13:06:15 -0400
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by insensate.co.uk (Postfix) with ESMTP id 55955C7492;
	Thu, 23 Aug 2007 18:06:13 +0100 (BST)
In-Reply-To: <46CD9ADC.9000006@enum.at>
References: <E1IODOl-0004pZ-CD@stiedprstage1.ietf.org>
	<46CD9ADC.9000006@enum.at>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <CAC79D84-EAA7-482B-A4CA-DFFE762D261E@insensate.co.uk>
Content-Transfer-Encoding: 7bit
From: lconroy <lconroy@insensate.co.uk>
Subject: Re: [Enum] Re: Last Call: draft-ietf-enum-calendar-service (A
	Telephone Number Mapping (ENUM) Service Registration for
	Internet Calendaring Services) to Proposed Standard
Date: Thu, 23 Aug 2007 18:06:03 +0100
To: Alexander Mayrhofer <alexander.mayrhofer@enum.at>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
Cc: enum@ietf.org, Rohan Mahy <rohan@ekabal.com>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Hi Alex, folks,
   I wholeheartedly agree.
This change helps, and avoids a potential problem.
The reason for this change is well explained.
Knowing in advance whether or not there was a bullet in the chamber
would be good :). iMIP Yes, CalDAV No.

---
One related point -
Q:  Should this rationale (with or without the wonderful "russian
     ENUM roulette, anybody?" comment) be added to the existing text
     for the Enumservice framework document?

IMHO, it is A Good Idea to highlight that RFC3761 doesn't let a client
readily go back and re-evaluate the remaining RRSet. I think it would
help people trying to fathom out which option fits their requirements,
as it is not always obvious WHY a specific sub-type is used rather than
letting the client sort it out through negotiation within the protocol.
On brief re-scan, the framework doesn't quite say that yet. Maybe this
could be added to the subset sub-section (3.2.3 bullet 2) of the frame-
work draft?

all the best,
   Lawrence


On 23 Aug 2007, at 15:34, Alexander Mayrhofer wrote:
> The IESG wrote:
>> The IESG has received a request from the Telephone Number Mapping WG
>> (enum) to consider the following document:
>>
>> - 'A Telephone Number Mapping (ENUM) Service Registration for  
>> Internet
>>    Calendaring Services '
>>    <draft-ietf-enum-calendar-service-03.txt> as a Proposed Standard
>
> Hi,
>
> (yes, i know that it's _very very_ late for this, and i hate to  
> receive
> similar comments on my documents... but - better late than never?)
>
> Two things (i start with the non-issue..)
>
> - I seem to have overlooked that the shortcut title of the document  
> still
> says "IM Enumservice", even though this is the calendar  
> Enumservice, seems
> to be a leftover from copying the other template.
>
> Now the harder issue: Subtypes.
>
> - In the light of the discussions around Enumservice classification in
> Chicago, i examined the type/subtype combinations, and i feel a bit  
> unease
> about not using any subtypes for this Enumservice, because this  
> Enumservice
> covers two completely different calendaring protocols (iMIP and  
> CalDAV). I
> consider being "ical" and "application class" Enumservice,  
> according what we
> added to the enumservices guide in the recent revision.
>
> A bit more about the subtyping decision:
>
> Keep in mind that a client is not allowed to "look" at the URI  
> scheme for
> choosing a ENUM records, so it can only guess whether the record  
> would be
> for an iMIP or an CalDAV address when there is no subtype given.  
> Only the
> type and subtype must be used to choose a NAPTR from a set of  
> records - so a
> client would not be able to find out whether a NAPTR refers to a  
> "iMIP" or
> "CalDAV" resource..
>
> That might well lead to problems when a client finds out that the  
> "ical"
> record it has just chosen lists a iMIP address, while the client only
> supports CalDAV. According to RFC3761, it can't "go back" anymore,  
> and try
> the other "ical" record, even if that would have contained a CalDAV  
> URI. So
> the client would fail to contact the calendaring resource, even  
> though it
> _would_ have been able to contact it in case it had chosen the  
> other record
> ("russian ENUM roulette", anybody?)
>
> - A second concern might be that there _could_ be calendaring  
> protocols that
> use http/https URIs as well, but don't represent CalDAV resources (who
> knows?). A client would have no chance in finding out which "http- 
> using"
> calendaring protocol the NAPTR addresses without contacting the actual
> calendar service.
>
> I'd suggest to change (yes, i know, 5 mins after 12) that Enumservice
> registration to two distinct registrations, both with a subtype, like:
>
> a) Name: "iCal"
>    Type: "ical"
>    Subtype: "caldav"
>    URI schemes: "http", "https"
>
> b) Name: "iCal"
>    Type: "ical"
>    Subtype: "imip"
>    URI schemes: "mailto"
>
> That would clarify to the client which calendaring protocol is in  
> use, would
> allow other potential calendaring protocols to use http/https as  
> well, and
> generally give me a better feeling about that Enumservice than the  
> current
> document does...
>
> Comments?
>
> (and, again, sorry for being late!)
>
> ---
> Alex Mayrhofer
> enum.at
>
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum


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



From enum-bounces@ietf.org Thu Aug 30 13:29:49 2007
Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IQnoA-0005Wo-OS; Thu, 30 Aug 2007 13:27:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IQno9-0005Wi-IO
	for enum@ietf.org; Thu, 30 Aug 2007 13:27:53 -0400
Received: from mail.songbird.com ([208.184.79.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQno8-0002Gt-4W
	for enum@ietf.org; Thu, 30 Aug 2007 13:27:53 -0400
Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35])
	(authenticated bits=0)
	by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id
	l7UHRVIV019571
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
	for <enum@ietf.org>; Thu, 30 Aug 2007 10:27:33 -0700
From: "Richard Shockey" <richard@shockey.us>
To: <enum@ietf.org>
Date: Thu, 30 Aug 2007 13:27:20 -0400
Message-ID: <010b01c7eb2b$05e540e0$11afc2a0$@us>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcfrIPoNxDNeJ+9eR+iV+WKqHDkbJgACgL/Q
Content-Language: en-us
X-Spam-Score: 2.9 (++)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4
Subject: [Enum] FW: I-D ACTION:draft-livingood-enum-voicemsg-00.txt 
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org



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