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

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 4 Jul 2003 14:05:57 -0400

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

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

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.

> 
> 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
> 

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.

> 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
> 

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.

> 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.

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.

> 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.
> 

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.

> 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?

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.

> Comment: 5.4
> 'E2IPv4+sip'
> 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.

> 
> 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?
> 

Heh.

> 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 ;-)
> 

Yes, no desire here to regurgitate the base standard.

Jon Peterson
NeuStar, Inc.

> Richard

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 5 Jul 2003 05:17:13 +0200

On fredag, jul 4, 2003, at 20:05 Europe/Stockholm, Peterson, Jon wrote:

> You'll note that the example from RFC2916 that showed a wildcard

You can have something like this (I think, straight from my head):

1.2.3.4.e164.arpa. IN CNAME 4.e164.arpa.
2.2.3.4.e164.arpa. IN CNAME 4.e164.arpa.
3.2.3.4.e164.arpa. IN CNAME 4.e164.arpa.

4.e164.arpa. IN NAPTR .... "!^+4(.*)$!sip:9876\[email-masked]!"

          paf

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 5 Jul 2003 05:14:06 +0200

> possible according to the syntax, what's the use-case that motivates

Because support for wildcards is a MUST when you implement the NAPTR 
record, which ENUM inherits from the DDDS application. If you don't 
implement it, you loose. You don't have a DDDS compliant implementation.

So, I don't understand why you do this recommendation. What is it 
supposed to help wit, as implementations still have to implement the 
regexp according to the NAPTR specification.

     paf