Subject: RE: [Enum] Questions Part 2

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 11 Mar 2003 17:09:17 -0500

More, as always, below.

Jon Peterson
NeuStar, Inc

> -----Original Message-----
> From: Michael Mealling [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2003 12:10 PM
> To: Peterson, Jon
> Cc: 'Richard Shockey'; 'Conroy, Lawrence ""(SMTP)'; [email-masked]
> Subject: RE: [Enum] Questions Part 2
> 
> 
> On Mon, 2003-03-10 at 14:56, Peterson, Jon wrote:
> 
> > [snip]
> > 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.
> 
> Not non-standard, just alternative methods of getting to a SIP server.
> 

Non-standard in the not-insignificant sense that RFC3261-compliant user
agents behave differently than the "vovi" draft would like them to.
Non-standard in the sense that because you used a different method to get to
the server, you need to make different requests than you might have
otherwise.

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

I hear what you're saying, but I intended my analogy to be a little more
narrow than that. To my mind, it would be like if, depending on whether you
found the HTTP server using the A record method or the NAPTR method, it
changed whether or not you could send POST requests to the HTTP server, and
moreover what kind of information was allowed to appear on any web pages you
got from the web server. The analogy would have to change something internal
to HTTP, the way that "vovi" changes things that are internal to SIP.

There's nothing wrong with your analysis of the web server case above,
though. I would note that we in the SIP community found it necessary and
useful to specify in our own standard the proper use of NAPTR records (as a
first resort) for discovering SIP resources in addition to an A record
method - perhaps if HTTP were to be revised today, they would do the same.

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

Well, not that I want to challenge anything about how HTTP and DDDS
interact, but let me play devil's advocate, here.

If a resource gets moved in HTTP, hopefully the server will use 3xx to tell
you of that rather than giving you a 404 and forcing you to go back to the
DNS. Otherwise, what would happen when people use the A record method, and
not DDDS, try to hit the web page - DDDS leads to a redirection, the A
record to a failure? Do you want the behavior for those that use the A
method to result in one web page, and the DDDS method another? You could
guarantee the same behavior by just sending 3xx from the HTTP server. What
are the implications for the use of HTTP if redirection is handled
intermittently by the DNS, depending on the URI resolution capabilities of
the client?

Consider the following text from RFC2616 section 10.3.2 (which describes
client behavior on receipt of 301):

   Clients with link editing capabilities ought to automatically
   re-link references to the Request-URI to one or more of the new
   references returned by the server, where possible. This response is
   cacheable unless indicated otherwise.

This text suggests that there is some benefit for clients in receiving an
HTTP redirection that might not be realized by redirecting in the DNS. So
what are the benefits of the DDDS way?

I've been applying roughly the same argument to SIP and ENUM in this thread.
Except ENUM, unlike DDDS, is not a general URI resolution system - ENUM is
only invoked under very specific conditions (when you happen to hold a
telephone number). I think the argument is even stronger in that case.

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

I agree that it's important that we only say that SIP works best when you
use AoRs and not contact addresses, and so forth, rather than mandating
something.

I think to some degree you're right, I am suggesting an applicability
statement about the use of SIP URIs. But the point is, I'm doing this in the
context of two proposals in front of this WG at the moment - let's set aside
for the moment whether they are compatible or competitive. The 'E2U+sip'
proposal is sufficient, in my estimation, as an enumservice for SIP - and we
appear to have some consensus to go forward with this proposal (i.e. this
document is currently a WG item). So no one is saying that ENUM and SIP
shouldn't interoperate. This is much more specific question of how ENUM and
SIP should interoperate. Clearly it's possible that some ways are better
than others (I can think of some really terrible ways no one has proposed
yet), and I've put forward ramifications (for SIP behavior) of choosing one
approach rather than another. The question is what we should standardize
here in the IETF.

Perhaps this need for applicability arises from the fact that SIP's use of
URIs (as opaque identifiers behind which services and capabilities can
change in real-time) is irregular. I don't know if there are other protocols
that use URIs in the same way. I'm not sure, though, why we would
necessarily think it's legitimate to 'treat identifiers differently' than
they were intended for any protocol. I would think that there are risks that
could arise from that, and in this particular thread it would seem there are
some significant problems that result from treating SIP's identifiers as if
they signified something other than what they do. SIP AoR URIs are
identities that serve as a conduit to a resource discovery and session
negotiation protocol.

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

---

From: [email-masked]
Date: Wed, 12 Mar 2003 07:22:57 +0200

Peterson, Jon writes:

 > Non-standard in the sense that because you used a different method to
 > get to the server, you need to make different requests than you might have
 > otherwise.

this started when i was asked to add voice:sip and video:sip support to
the enum module of a sip proxy.  in many cases enum lookups are done by
proxies and not directly by sip uas (many of which don't today have enum
lookup capabilities).

without caller preferences in the request (which is the normal case
today) what should my proxy do if it finds both voice:sip and
voice:video record for the aor of an invite?  should it scan the sdp of
the invite in order to find out if it contains mlines for video or
voice?  what if it has both?  in any case, the result is behavior which
is very different from how sip proxies work today.

-- juha

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Wed, 12 Mar 2003 10:03:45 +0000

>is very different from how sip proxies work today.

To which I reply:
Good Morning Juha, folks,

One thing's for sure, with the PUA you are not going to do the "interactive"
tie-breaking that has been discussed.

The proxy still resolves a destination address the same as it always has
- in this case it has an E.164 number and so needs to do an ENUM lookup.
It doesn't HAVE an AoR at this point.

First, a side-comment: in the following text I'm making the assumption that
the proxy has a valid DDDS client, and so the DDDS round will complete with
a single Result. Thus, if there are two sip entries, the proxy doesn't just
fork to them both. See 2916bis-04 section 2.6 for a clarification on Note 1
of RFC3402. In particular, pargraph 3 applies to the Proxy.

The proxy doesn't have a local end user to break the tie in a DDDS round (from
the Order fields being the same value) so it uses the standard approach of
taking the entry with the "best" preference field value.

This whole discussion has been on the last two paragraphs of section 1.3
of 2916bis-04, and in particular the last sentence. The standard SIP proxy
has no local policy, so I wouldn't expect it to over-ride the preference
field value.

Not having a local end user to whom to present all of the NAPTRs for "tie
breaking", the proxy falls back to using preference as a tie breaker. I'm
sure that there are other views on this, but that process will work as it
always has.

In this case, 'voice:sip" and 'video:sip' are treated exactly the same
as plain, unlabeled 'sip'. In your case of having both a 'voice:sip' and
a 'video:sip' entry in ENUM for the E.164 number you have, then you have
two SIP AoRs...select based on preference field value for these entries.

(BTW, I hope you meant "video:sip" rather than "voice:video" - if not
then you're on your own :).

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