Subject: RE: [Enum] Questions Part 2

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 10 Mar 2003 14:56:44 -0500

Answers part 2 below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]]
> Sent: Monday, March 10, 2003 7:10 AM
> To: Peterson, Jon; 'Conroy, Lawrence (SMTP)'; Peterson, Jon
> Cc: [email-masked]
> Subject: Re: [Enum] Questions Part 2
> 
> 
[snip]
> 
> For purposes of clarity ...
> 

Yes, we need more of that, no doubt. I'm sorry if this debate has been
rather murky. I've been hoping to post a summary (for general consumption)
of the issues Mr. Conroy and I have been discussing soon. Maybe we can use
some SF agenda time for this...?

> A. I've seen no postings from authoritive H.323 types so I'm wondering if 
> the discussion on SIP enumservice granularity ..is applicable for that 
> protocol.  The question then ..Is H.323 different enough from sip in the 
> negotiation of capabilities that granularity aka voice:h323 is acceptable.
> 

I hope that Ms. Levin or other advocates of H.323 enumservice proposals can
speak to that. I do think that the treatment of URIs and registration in
H.323 is different, and therefore it is conceivable different conclusions
could apply to H.323.

> B. What of the case where I have multiple SIP service providers... I have 
> sip based IM from Microsoft and a sip based service from ... iptel 
> ..whomever.  What of the case where I as the ENUM registrant need to 
> distinguish between the two
> 
> im:sip .....use this AoR
> voice:sip ..use this AoR.
>
> the reason being that neither my sip based IM provider or SIP based voice 
> provider has the capability of negotiating a redirection since neither 
> service gives me the ability to configure my account appropriately.
> 

That doesn't happen to be discussed in the mail to which you are replying
(which was about the internals of my proposal, not "vovi"), but has been the
subject of lengthy previous correspondence in this thread. A few
(non-exhaustive) points about this:

First, it is worth pointing out that if those condition arose, it would be a
SIP problem, and one that is orthogonal to ENUM. If a SIP service doesn't
give you the capability to register arbitrarily, it probably isn't SIP RFC
compliant (by the book, registrars don't evaluate the contact addresses in
registrations, and the manner in whch registrars accept, store and expire
them is specified in some detail). iptel.org, for example, doesn't happen to
have this problem. Planning our enumservices for SIP around non-compliant
SIP implementations seems somewhat questionable.

This problem is always solvable in SIP without resorting to any other
protocol or mechanism to compose the URIs. Even if we could solve this
problem with ENUM, then we would only have solved the problem for users that
hold your telephone number, not for the users of native SIP URIs (who
apparently would have to juggle two URIs). If SIP behaves differently when
you use ENUM than when you use SIP without it, I think there's something
wrong with the way we're leveraging ENUM.

Finally, if we take the "vovi" proposal outside the context of solving an
artificial constraint in SIP, it still has various internal coherence
problems that have also been discussed in this thread (relating to the
purpose of service labels, the efficacy of policies enforced by labels, and
the question of how useful these labels are for expressing capabilities of
SIP endpoints). By standardizing "vovi" labels for SIP we would be
encouraging the use of these artificial constraints (service-specific AoRs)
in SIP - essentially, encouraging non-standard SIP deployments and behavior.
It would be like if the existence of an enumservice pointing to a web page
changed something about how you provision or reach the page. I would have
hoped that ENUM would be more transparent to the services it advertises -
that it would be a directory of URIs learned from a telephone number.

> 
>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Richard Shockey, Senior Manager, Strategic Technology Initiatives
> NeuStar Inc.
> 46000 Center Oak Plaza  -   Sterling, VA  20166
> Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
> <mailto:[email-masked]> or <mailto:[email-masked]>
>   <http://www.neustar.biz> ; <http://www.enum.org>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Michael Mealling <[email-masked]>
Date: 11 Mar 2003 15:09:42 -0500

> in SIP - essentially, encouraging non-standard SIP deployments and behavior.

Not non-standard, just alternative methods of getting to a SIP server.

> that it would be a directory of URIs learned from a telephone number.

This is exactly what we did with the URI Resolution DDDS application.
Given 'http://bar.foo.com/baz/foobaz' you can use two methods to get to
the HTML resource bound to that URI. You can use the 'http:' standard
method (get the A record for the host part and connect to that host via
HTTP and request the page) or you can destruct the URI by looking up
NAPTR records starting at http.uri.arpa. Once you find a terminal NAPTR
you contact that server via some metadata protocol and ask it where you
can find a copy of that resource. If you look at the HTTP standard it
doesn't mention anything about using the DDDS. Does that make the URI
Resolution Application invalid? No. Its just another method of finding
out about the thing associated with some identifier.

The URI Resolution application was always intended to be the method of
last resort. If you received a 404 Not Found you could use the DDDS
method to find someone who could tell you where it got moved to. With
respect to ENUM, I think that's also valid to have multiple methods for
getting information/services associated with some TN. 

I think its extremely dangerous for protocol specs to make applicability
statements about things external to the actual on the wire use of
identifiers. Especially if that protocol can deal with generic URI
schemes. IMNSHO, SIP can suggest that SIP works best when one AoR is
used and all, but it should not be allowed to make applicability
statements about other systems that may choose to treat identifiers
differently and which may desire to inter-operate with SIP.

-MM