Subject: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt

From: Richard Shockey <[email-masked]>
Date: Wed, 02 Jul 2003 16:39:13 -0400

FYI

>To: IETF-Announce: ;
>Cc: [email-masked]
>From: [email-masked]
>Reply-to: [email-masked]
>Date: Wed, 02 Jul 2003 16:33:49 -0400
>Subject: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt
>Sender: [email-masked]
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.0.12
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
>         <mailto:[email-masked]?subject=unsubscribe>
>List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
>         <mailto:[email-masked]?subject=subscribe>
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Session Initiation Proposal Investigation 
>Working Group of the IETF.
>
>         Title           : Using ENUM for SIP Applications
>         Author(s)       : J. Peterson, H. Liu, J. Yu, B. Campbell
>         Filename        : draft-ietf-sipping-e164-03.txt
>         Pages           : 22
>         Date            : 2003-7-2
>
>Although SIP was one of the primary applications for which ENUM was
>created, there is nevertheless a need to define procedures for
>integrating ENUM with SIP implementations.  This document illustrates
>how the two protocols might work in concert, and clarifies the
>authoring and processing of ENUM records for SIP applications.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-03.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>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-sipping-e164-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:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-ietf-sipping-e164-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.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-sipping-e164-03.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipping-e164-03.txt>

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 3 Jul 2003 12:46:58 +0200

Hi all,

I have some comments and also some serious problems with this draft.

General comment:

It may be a dogma in the religion of SIP, but SIP is not the center of
the world ;-)

General comment: what kind of RFC this will be?

The good news first: it is nice to hear that "the most widespread
application for
SIP today is voice", or "the most common application in SIP is
telephony" and
that "in most cases, these are request for a telephone session (voice
communication)"

Comment: 

I am getting a bit tired to be lectured permanently without asking for
it that there is two
types of SIP URIs (if this is such a problem, then why not put a
parameter or create
a sipL: URI) and no contact addresses should appear in ENUM. As far as I
know from
praxis, nobody ever tried to do this.

 "SIP URIs in ENUM do not convey capability information.  SIP has
      its own methods for negotiating capability information between
      user agents (see SDP [13], the use of Require/Supported to
      negotiate extensions in RFC3261, and callee capabilities [11]);
      providing more limited capability information within ENUM is at
      best redundant and at worst potentially misleading to SIP's
      negotiation system.  Also, addresses-of-record do not have
      capabilities (only devices registered under an address-of-record
      have actual capabilities), and putting contact addresses in ENUM
      is not recommended."

Amen, btw, a tel URI is also an address-of-record (better: a name) and
does not
convey any cabability information. On the other hand, if an "author"
want to put capability
information in ENUM, it is his problem

Comment: 
"Only one SIP URI appears in an ENUM record set ..."
This is up to the ENUM subscriber, is it necessary for them to read this
document?
See also section 5. Authoring of NAPTR records

Comment: 5.1
"It is strongly RECOMMENDED that authors of NAPTR records use the
'E2U+sip' 
service field whenever the regexp contains a SIP address-of-record URI."

Are we doing commercials in IETF drafts?. If another enumservice with
sip URI
is registered with IANA the "authors" may use, if not, not.

Major problem: 5.2
5.2 Flags in NAPTR RR

"Authors of NAPTR records MUST use the terminal "u" flag when
'E2U+sip' is specified as a Service field."

Why?, and if this is so, it must go into the draft-ietf-enum-sip IANA
registration.

Major problem: 5.3
"Authors of
   records intended to be used for SIP applications SHOULD always use a
   greedy regexp; no use-cases have been identified today in which a
   different antecedent is necessary."

I strongly object this.
First, the use of regular expessions is a feature in ENUM and DDDS,
second, there are use cases (e.g. in wildcards) and
third, if there is no-use cases, why is are regular expression there in
the first place?

Comment: 5.4
"NAPTR records that
   are intended to be used for session initiation (including SIP
   telephony) SHOULD use a SIP URI."

"It is RECOMMENDED that authors of ENUM records should always use the
   SIP or SIPS URI scheme when the service field is 'E2U+sip', and the
   URIs in question MUST be addresses-of-record, not contact addresses."

Another commercial?

Comment: 5.4

'E2IPv4+sip'

What is this?

Comment: 5.6

"$ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa.
      IN NAPTR 100 10 "u" "E2U+sip"    "!^.*$!sip:[email-masked]!"
.
      IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!mailto:[email-masked]!"
."

?
I am glad that at least "email:mailto" is allowed beside SIP ;-) No spam
problem?

Comment: 5.

"These guidelines do not by any means exhaustively describe the NAPTR
   algorithm or the processing of NAPTR records; implementers should
   familiarize themselves with the DDDS algorithm and ENUM before
   reviewing this section."

MM will like to hear this one ;-)

Richard

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Wednesday, July 02, 2003 10:39 PM
> To: [email-masked]
> Subject: [Enum] Fwd: [Sipping] I-D 
> ACTION:draft-ietf-sipping-e164-03.txt
> 
> 
> 
> FYI
> 
> >To: IETF-Announce: ;
> >Cc: [email-masked]
> >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
> >http://www.ietf.org/shadow.html or 
> >ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> Richard Shockey, Senior Manager, Strategic Technology 
> Initiatives NeuStar Inc.
> Voice +1 571.434.5651 Cell : +1 703.593.2683,  Fax: +1 
> 815.333.1237 <mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: "Martin Streller" <[email-masked]>
Date: Fri, 4 Jul 2003 20:44:02 +0200

Hello,

> what's the use-case that motivates
> wildcards for ENUM?

You can hook up an ENUM client and query for
     +49 7031 73009 88
our support line.
As a result you'll receive an h323 wildcard NAPTR RR
that's eventually of interest for you. 
Replace h323 with sip and you got your use-case.

This single NAPTR RR serves the whole range 
of our two-digit extensions.

Regards, Martin
--
Martin Streller
innovaphone AG
Software Engineer
Cicerostr. 2A
D-10709 Berlin
Tel.:  +49 (30) 890 44 98 73
Tel.:  +49 (7031) 730 09 73
Fax:  +49 (30) 890 44 98 96
http://www.innovaphone.com

-----Ursprüngliche Nachricht-----
Von: Peterson, Jon [mailto:[email-masked]]
Gesendet: Freitag, 4. Juli 2003 20:06
An: 'Stastny Richard'; Shockey, Richard; [email-masked];
[email-masked]'
Betreff: RE: [Enum] Fwd: [Sipping] I-D
ACTION:draft-ietf-sipping-e164-03.txt

Since the original mail was cross-posted between SIPPING and ENUM, I'll send
this reply to both.

> It may be a dogma in the religion of SIP, but SIP is not the center of

If you sent an ENUM WG item to another WG, I can imagine someone making a
similar comment - "why does this document talk about ENUM all the time, this
is a WG about xyz". This document is a SIPPING WG item, not an ENUM WG item.
For this document, SIP is effectively the center of the world, yes. I
imagine other protocols might similarly describe their relationship to ENUM.
But also note that our document talks about more than just ENUM - it also
discusses what you might do as a SIP UA when you can't use ENUM, and so on.
It also happens to more fully specify ENUM behavior, since we hope that the
use of ENUM will be the common case for handling telephone numbers in SIP.

> a sipL: URI) and no contact addresses should appear in ENUM. 
> As far as I know from praxis, nobody ever tried to do this.
> 
does not
> want to put capability information in ENUM, it is his problem
> 

Well, I'm sure everyone on the ENUM mailing list has had an earful of these
arguments before, agreed. But the products of the IETF are intended for more
general consumption than just the participants of any particular WG.
SIP/PING WG folk, even, might not have followed these ENUM threads. So maybe
there are people out there who, unlike yourself, have not yet grasped this
point. It was formerly a subject of confusion, and it might become one
again. I hope it isn't too annoying to have this sort of text in the
document.

document?
> See also section 5. Authoring of NAPTR records

Well, these do aspire to be guidelines for authors of ENUM NAPTR records for
SIP, so yes, we do hope to advise ENUM subscribers, or whomever provisions
NAPTR records on their behalf. Obviously, subscribers can read/follow our
document or not, as they wish.

'E2U+sip' 
> Are we doing commercials in IETF drafts?. If another enumservice with sip
URI
> is registered with IANA the "authors" may use, if not, not.

I don't really look on this instance (or the others you point out in 5.4) as
"commercials" - they are showing a RECOMMENDation from the SIPPING WG on how
the documents in the ENUM WG can be used to assist SIP services. If there
were multiple possible options for SIP enumservices, surely for consistency
it makes sense for the SIPPING WG to make a recommendation? This kind of
recommendation is made all the time in IETF documents.

Authors of NAPTR records can, of course, reject our advice, and new I-Ds can
be authored that teach alternative approaches to authoring. And agreed,
another ENUM service might become an RFC and accordingly be registered with
the IANA.

If you want to argue further that the "E2U+sip" enumservice should not be
recommended (and note that it is just RECOMMENDED, not REQUIRED, and then
only with the caveat that this enumservice is applicable solely to
addresses-of-record), I'd suggest pursuing this directly on the SIPPING
list. As far as I know, the consensus of the SIPPING mailing list is that
the "E2U+sip" enumservice is sufficient.

> Why?, and if this is so, it must go into the draft-ietf-enum-sip IANA

Good catch - although I'm not sure that I read in rfc2916bis's enumservice
registration template that one must specify flags that are meaningful for
enumservices within enumservice registrations. But still, my text is really
left over from course corrections necessary based on ol' RFC2916 - Section
2.4.1 of RFC2916bis does specify that only the "u" flag is currently defined
for ENUM. So I agree with you, Section 5.2 doesn't need to be in the SIPPING
document - 2916bis covers this adequately. I'll take it out.

> third, if there is no-use cases, why is are regular 

I agree this is an important issue. While I acknowledge that "wildcards" are
possible according to the syntax, what's the use-case that motivates
wildcards for ENUM?

This is a question I've posed many times, and I've never gotten a good
answer to. You'll note that the example from RFC2916 that showed a wildcard
has not been repeated in rfc2916bis. The old example showed a record set for
6.4.e164.arpa, and the antecedent of the regexp contained "!^+46(.*)$!".

The point I raised about the example was that the "+46*" regexp antecedent
didn't do anything - if delegation to 6.4.e164.arpa got you to this record,
then of course the regexp was going to match with a leading "+46*".

There's no question that regexps are valuable for other DDDS applications -
but most DDDS applications don't have anything like ENUM's telephone number
resolution system to narrow selection down to a specific record set as a
part of DNS operations. The regular expression is there, for example, to
match against URN components in order to determine which substitutions are
valid - I'd look at examples 5.2 and 5.3 in RFC3404 to see how it would be
used. It isn't at all clear that a comparable function is necessary or
useful for ENUM - I'm not saying that I'm sure it's not useful, but I am
saying that clearly ENUM works without it, and to my knowledge there are no
existing use-cases for supplying a regexp antecedent for ENUM NAPTR records.

Also, note that the wildcard example begs questions about partial numbers
that we're trying to pass over in silence, at least in the current version
of RFC2916bis. If you can provide a meaningful use case that doesn't involve
partial numbers and/or gateway location that uses wildcards, I'll happily
relax this language.

> What is this?

A rhetorical example, as the surrounding context hopefully indicates. It's
not meant to be a real enumservice, but is rather a theoretical enumservice
that one might invent if one's underlying assumptions were different. Again,
I think that is well substantiated by the text of the end of 5.4.

>       IN NAPTR 100 10 "u" "E2U+sip"    "!^.*$!sip:[email-masked]!" .
>       IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!mailto:[email-masked]!"."
> 
> ?

Heh.

> MM will like to hear this one ;-)

Yes, no desire here to regurgitate the base standard.

Jon Peterson
NeuStar, Inc.

---

From: "Martin Streller" <[email-masked]>
Date: Sat, 5 Jul 2003 12:32:59 +0200

Hi Jon.

yes you're right, it's a gateway location application.

The NAPTR:
$ORIGIN 9.0.0.3.7.1.3.0.7.9.4.e164.arpa.
;  NAPTR   order   pref    flags   service         regexpression  replacement
*  NAPTR   100     100     "u"    "E2U+h323:voice" "!^\+49703173009(.*)$!h323:\[email-masked]!" .

The outcome of a query for +49 7031 73009 88 :
h323:[email-masked]

This wildcard record is hosted officially by Deutsche Telekom,T-Systems within
a BIND9 Dns server (with the exception that every \ must be written as a \\).

Martin

-----Ursprüngliche Nachricht-----
Von: Peterson, Jon [mailto:[email-masked]]
Gesendet: Freitag, 4. Juli 2003 22:48
An: Martin Streller; [email-masked]'
Betreff: RE: [Enum] Fwd: [Sipping] I-D

I think the example would need to be more concrete for us to understand how
you're using wildcards - what does the NAPTR record look like? And the
ORIGIN?

Having a single NAPTR record serve an entire 100-number range sounds like a
gateway location application to me.

Jon Peterson
NeuStar, Inc.

> From: Martin Streller [mailto:[email-masked]]
> Sent: Friday, July 04, 2003 11:44 AM
> To: Peterson, Jon; [email-masked]
> Subject: AW: [Enum] Fwd: [Sipping] I-D