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 16:47:42 -0400

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.

> -----Original Message-----
> 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
> ACTION:draft-ietf-sipping-e164-03.txt
> 
> 
> 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.
> 
> > 
> > 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
> >  
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 

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

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sat, 5 Jul 2003 00:12:22 +0100

At 4:47 pm -0400 4/7/03, Peterson, Jon wrote:
>  > In response to Martin's answer to Jon's question on the use case 
>for wildcards:
>  >
>>  Hello,
>>

To which I add:
Hi Jon, Martin, folks,
  I think I understand the wish to use wildcards; it's extremely
tempting if one has a set of H323 or SIP phones. I also understand
the concern that these can be like a loaded shotgun - powerful but
dangerous. We agonized over this one in the ETSI trials document.

However...a gateway location application?
Not exactly - if one uses a match term in the consequent part,
then isn't this is a single entry that generates a set of h323 or SIP
URIs (depending on the particular phone number/AUS passed)?

I had thought that a NAPTR in a wildcard will act as a gateway location
application only if one has a greedy regexp. What am I missing here?

all the best,
   Lawrence
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sat, 05 Jul 2003 01:52:43 +0200

<snip>

Basic understanding how wildcards in DNS work/are a problem.

	jaap

---

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

> Basic understanding how wildcards in DNS work/are a problem.

Yes, but _if_ the DNS community say "using wildcards in DNS is ok" 
_then_ ENUM will be able to use it fully as we inherit the regexp in 
the DDDS specification.

With my DNS hat on, I would still though say "if you use wildcards in 
DNS, you really really really must understand the implications, so you 
better try to solve the problem you have in some other way first".

    paf

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 07 Jul 2003 11:08:30 +0200

I think we are in violent agreement here.

	jaap