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

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 7 Mar 2003 03:26:57 -0500

Some notes inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Conroy, Lawrence (SMTP) [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 5:09 PM
> To: Peterson, Jon; 'Brandner Rudolf'; [email-masked]';
> [email-masked]
> Cc: [email-masked]; [email-masked]'; [email-masked]
> Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt
> 
> 
> Hi Jon, Folks,
>     Mr. Conroy? - Ouch!

I almost always address my colleagues in the IETF by their surnames on the
mailing lists - no offense was intended.

> 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 do think there are cases where you can get into trouble with this, but I
have no doubt that there are implementations in which SIP and ENUM entries
are managed in the fashion of the "vovi" draft. Mr. Stasny demonstrated such
at one of the prior IETFs, if memory serves. Unfortunately, there are
implementations of a lot of technology that are well-meaning, and beneficial
to users, but which still are not aligned with IETF standards.

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

Sure, though as an aside there's some question in the SIP case if there are
more sophisticated policy instruments that can be applied to that problem
than just keeping separate accounts. Rudi's case, anyway, seemed to be one
where he wanted to be able to reach people with either voice and IM and was
kind of foxed because of some constraint that prevented them from having a
unified single service. I was further exploring that constraint.

I have numerous SIP AoR's myself - I have one for FWD, one for iptel.org,
etc. The underlying question here, though, for the "vovi" proposal is one of
how my devices are associated with these AoRs, and what capabilities are
available at each of these AoRs. 

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

One concern is that if we publish multiple alternative SIP enumservices as
standards, implementers will probably have no choice but to support all of
them, with the different behaviors that would entail. Not the most desirable
outcome, if we can come to a consensus on one method it would be preferable.
I think Darwinism should be a last resort.

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

Glad we agree about that. But see below...

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

Well, while of course I think this is good counsel, I'm not sure it's really
compatible with the "vovi" proposal as I understand it. The problem is that
SIP AoRs don't have 'capability' as such - an AoR isn't a 'voice' AoR or
'video' AoR. A device that registers under an AoR has voice or video
capabilities, and for the duration of the registration, those capabilities
become available to user agents that send requests to the AoR.

So, effectively, by saying that an AoR supports 'voice', you are assuming
that some contact address representing a device that supports voice is
permanently registered under it - but SIP assumes that registrations are not
permanent in this way. URIs that represent devices (which are commonly used
as contact addresses) do have these sorts of permanent capabilities, though
- so I assumed you must be talking about them. 

Similarly, by provisioning that a URI has 'voice' capability in the DNS, you
are putting that very 'highly dynamic information' about registrations in
the DNS, as far as I can tell.

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

Of course it won't stop people from doing the wrong thing. But our point
here is to generate standards that recommend the right thing. People can and
will implement all sorts of non-standard stuff anyway.

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

Please do let me know if I misunderstand the draft on any of the point
above.

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