Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 6 Mar 2003 19:06:23 -0500

Thanks Mr. Conroy, and you are quite correct to ask - I should clarify that
I am not speaking here as Transport-Area-Director-elect, or something, but
just as a working group participant. The transition is slated to occur in
the middle of the SF IETF meeting (after ENUM meets, incidentally). Even
afterwards, I wouldn't expect to be seeing ex cathedra pronouncements from
me here anytime soon. 

That much said, I do think that last sentence of mine cited below is good
advice. I think it would be inadvisable to base enumservices for any IETF
protocols on assumptions that are incompatible with their respective
specifications.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Conroy, Lawrence (SMTP) [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 2:30 PM
> To: Peterson, Jon; 'Brandner Rudolf'; [email-masked]'
> Cc: [email-masked]; [email-masked]'
> Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt
> 
> 
> At 4:47 pm -0500 6/3/03, Peterson, Jon wrote:
> >I wanted to make some comments about this issue.
> 
> <snip>
> 
> >We shouldn't try to mandate that implementers and users 
> cannot use SIP is
> >ways other than its designers intended - such a mandate 
> would be pointless.
> >What we should do, however, is not produce standards that use other
> >standards incorrectly, or misunderstand their applicability. 
> These proposals
> >are essentially describing an alternative architectural 
> model for SIP, one
> >that is not friendly to the architecture in the SIP 
> specification. In this
> >strawman version of SIP, it might appear that ENUM provides 
> capabilities
> >that SIP lacks and desperately needs. But from my vantage 
> that need is
> >illusory. Let's not standardize a way of using ENUM and SIP 
> together that
> >makes assumptions contrary to the way SIP can and does work.
> >
> >Jon Peterson
> >NeuStar, Inc.
> 
> Hi Jon, folks,
> First, congrats.
> Second, are you speaking Ex Cathedra here?
> (Particularly the last sentence)
> 
> 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.
> 
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Fri, 7 Mar 2003 01:09:04 +0000

Hi Jon, Folks,
    Mr. Conroy? - Ouch!
Thanks; I guessed that but it needed to be said.

Re. Last sentence - yup, agreed; trying to break any protocol with any
enumservice spec is wrong.

Whether or not draft-brandner-enumservice-vovi-00.txt is incompatible
with the SIP spec is a question - I don't think so as I use SIP and
ENUM entries like this, so we must have not phrased it correctly :(

I'm not REQUIRED to use a single AoR, no more than I need a single
email address. I COULD use a single email address and filter/redirect
according to my policies. However, I choose to use two different
accounts - one for basic emails that will get SMS'd to me and the
other for "normal" email (i.e. the stuff telling me that I can add
3 inches in a week, ...).

Nowhere in the draft was it ever intended that folk MUST use these
enumservices for their SIP URIs. If folk want to use a single SIP
service, fine. (Nor does it say or imply that in ETSI TS102 172).
Heck, folk can even use a single 'h323' enumservice of it gets
them through the night.

Re. stating that DNS is not the place to to put highly dynamic
information; we had thought, in the immortal words of John Cleese
and Connie Booth, that that was "stating the bleedin' obvious".

However, we can put that into the drafts if it helps.

Note that the URIs we had ASSUMED that folk would put into ENUM
would be AoRs, not transient contact addresses - that's a idea
that simply hadn't occurred to me people would even consider.

Again, we can add text that says that you shouldn't avoid a SIP
Registration by putting a SIP contact URI in it.

That, of course, doesn't stop really determined folk putting IP
addresses and SRV records into their ENUM domains, but the A record
is always with us (or the AAAA, or ...).

Seems to me that the confusion here is a great deal of assumption
on what this simple draft is actually saying, and my lack of
understanding of the odd things folk might think of doing with it.

We can spell out these things in the next turn - we're in blackout
now so it won't be out until after SF.

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.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: [email-masked]
Date: Fri, 7 Mar 2003 07:56:22 +0200

> service, fine. (Nor does it say or imply that in ETSI TS102 172).

may be so, but i was told that based on this draft, authorities in one
european country had mandated the use of either voice or video service
in SIP enum entries that correspond to phone numbers of that country.

-- juha