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

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 6 Mar 2003 20:09:46 -0500

Some notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Mealling [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 3:15 PM
> To: Peterson, Jon
> Cc: 'Brandner Rudolf'; [email-masked]'; [email-masked];
> [email-masked]'
> Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt
> 
[snip]
> > 
> > When your argument is predicated on a benefit that SIP user agent 
> > clients will derive from holding multiple identifiers for a target
> > that each represent a different service or capability, this shows up
> > to SIP people as a misunderstanding. SIP user agents would not 
> > benefit from this, and in fact, there are ways in which it seems
> > obviously detrimental. It is moreover not how most SIP user agents
> > operate - they assume that you plug in a single URI and let SIP take
> > care of the rest.
> 
> I think this is where the misunderstanding is coming in. You are
> incorrectly assuming we are talking about a SIP user agent in its
> fullest sense when what we are talking about is a user agent that does
> other things better. It isn't a fully compliant SIP user agent. Its
> implementation of SIP would be only what is required to accomplish one
> single task (voice, or IM, not both).
> 

Well, I don't necessarily think this was Mr. Brandner's example - he was
speaking to a case in which a particular user had two SIP URIs, without
reference to compliance of user agents, and whatnot. His problem seemed to
have something to do with a purported inability to register URIs
cross-domain. 

I would point out, though, that I think it is questionable to build our
cases for SIP enumservices on the assumption that SIP user agents are not
SIP-compliant.

> > <reasons that multiple identifiers for SIP are bad deleted because
> > there is no argument with them>
> > 
> > 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. 
> 
> The point is not that SIP is being misunderstood. Everyone knows full
> well that SIP is meant to hide other identifiers this way. We know that.
> But we're coming from a world where SIP is not and probably never will
> be widely adopted for the simple reason that it just doesn't do what's
> needed. 
> 

Please do enlighten us then - but perhaps we should move this thread to SIP
or SIPPING?

I'm not really sure where this is going... certainly, if SIP is for whatever
reason inadequate, I would welcome you to use another protocol of your
choosing, or propose ways that we might improve SIP. I thought what we were
trying to do in this thread was to discuss an enumservice appropriate for
SIP URIs. I hope we'd all agree that an enumservice for SIP is not supposed
to change the way SIP operates, right?

What's being misunderstood by some, I suspect, is the justification for
'hiding' identifiers in SIP, and the material technical differences between
doing so in SIP and doing so in ENUM (four of which I discussed in my last
mail, and a fifth was mentioned by Mr. Heinanen). 

If you have no argument with the four points of mine, then hopefully we're
on the same page that using multiple SIP identifiers in ENUM is problematic,
and that there's no technical impediment to using a single identifier in
ENUM. This is only point I was trying to establish, in response to Mr.
Brandner's mail.

> > These proposals are essentially describing an  
> > alternative architectural model for SIP, one that is not friendly to
> > the architecture in the SIP specification. 
> 
> We're not describing an alternative architectural model for SIP. We're
> describing an architectural model for something wholly and completely
> different but which allows someone to use a SIP connection as a tunnel
> for that application. Its like suggesting that since web browsers can
> handle gopher: URLs that HTTP is redefining the gopher architectural
> model.
> 

Again, you're really losing me here. I agree that ENUM describes a generic
architecture for converting TN numbers to URIs associated with particular
protocols or services, and that is indeed broader than SIP. A particular
device on which a SIP implementation resides may have many other
applications that handle other sorts of protocols and services. None of this
is being contested here, as far as I know. I thought we were talking about
enumservices for SIP.

I think I do understand your analogy in the last sentence, but I'm not sure
it applies. I acknowledge that there is a 'service browser' concept for ENUM
in circulation, and I don't necessarily have a problem with that idea per
se.  But concepts like "vovi" entail behavioral and architectural changes
for SIP elements. They may make it harder to do SIP's job. I have no doubt
that these same concepts are more applicable to other protocols.

> > 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.
> 
> Again, we're not attempting to standardize any behavior for SIP. What
> we're after is something more than SIP or any particular protocol. It
> just so happens that you can use SIP with it.
> 

I do hope that's what ENUM is after, yes. But that's not what Mr. Brandner's
mail, or the vovi draft in so far as it relates to SIP, seemed to be
speaking to. I certainly want ENUM to be able to use SIP, and vice versa, in
a way that is profitable for both.

Was there something we disagreed about, here?

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