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

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 6 Mar 2003 16:47:10 -0500

I wanted to make some comments about this issue.

From my perspective, this discussion is really not about ENUM at all. ENUM
is a system for transforming one kind of identifier into another kind of
identifier. This is a question about how SIP is used. The problem is that
you describe a scenario below for the usage of SIP in which it is preferable
for users to have multiple identifiers for a target, each of which is
associated with a different capability or service - it really doesn't matter
whether these identifiers were acquired from ENUM, from a web page, or
wherever. The only important point is that SIP is not a protocol that
profits from having multiple identifiers sorted by the capabilities
associated with these identifiers. One of the primary purposes of SIP is to
due away with the need to learn multiple identifiers for a particular user -
this is the whole point of dynamic registration, forking, presence and many
of SIP's other virtues.

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.

The reason why this is 'bad' is that this model suggests that the way to
manage the set of URIs you use for SIP is to publish them in ENUM, rather
than registering them in SIP. This is problematic because:

- ENUM is not necessarily a prerequisite for using SIP - sometimes people
may try to reach me with SIP without first using ENUM. Because I want to
make all of my identifiers available to people who use SIP without
consulting ENUM first (because they already have a URI, not a telephone
number), we cannot replace SIP registration with ENUM records - we'd have to
keep them in SIP as well. Provisioning multiple URIs in ENUM will always
have to be redundant with SIP registration. This raises questions of
synchronization and the usual issues that arise with (undesirable)
redundancy.
- SIP has a built-in method for registering a URI under another URI, with
lots of apparatus for security, privacy, refreshes, expirations, priority,
capability, and so on.  Any SIP compliant (2543 or 3261) user agent will
support this method.  Most SIP user agents register automatically when they
boot or come online. I don't think we've yet identified a way for
applications to similarly publish information into ENUM. For many
applications that would be identified by ENUM (like email clients or web
pages) the concept isn't even meaningful.
- SIP registrations may have very brief durations. I may only be associated
with a device (and hence the devices URI) for a short amount of time. It
isn't clear that the DNS is the best place to express very short term
relationships of this nature. DNS scales most effectively when entries can
be cached for more significant durations (at least hours). SIP is optimized
for real-time establishment and termination of registrations.
- The capabilities expressed by primitives like 'voice' and 'video' are both
too coarse and too strict for SIP. They are too coarse because they will
always be redundant with SIP's own SDP-based negotiation upon session
establishment, which gets into far greater details about what 'video'
entails (codecs and intervals, and so on) - if two SIP endpoints both
support 'video' that doesn't mean they'll be able to communicate. The
primitives are too strict because the SIP process is designed to find the
best way for two user agents to communicate, taking into account the
capabilities and preferences of both. Designating that a SIP URI is a
'voice' URI doesn't even really make sense. If you don't need this
capability negotiation function of SIP, you probably don't need SIP as such.

In the example below, users do not register their Redmond SIP URI under
their Richardson SIP URI or vice versa. There is presumably some
non-technical reason for this (presumably service provider policies forbid
it). However, in light of RFC3261 I find this somewhat unlikely. There's no
mechanism that allows a registrar to 'reject' a registration of a contact
URI under an address-of-record on the grounds that that they don't like that
contact - there's not a way to reject particular contacts at all. Registrars
don't even inspect the contact URIs themselves for semantics - they are a
black box to the registrar which it doles out when people ask how to reach a
user. The registrar doesn't even have to understand the URI scheme. Now, the
entire registration can be rejected if the registering user agent isn't
authenticated, of course, but this is just a matter of whether or not a
shared secret is known by the operator of the user agent. I'm not sure what
enforceable constraint could be applied that would block these sorts of
Redmond-under-Richardson registrations. I suspect that this is a kind of
pseudoproblem. I have no doubt that users could elect to selectively
register at different registrars, thereby impoverishing SIP's overall
functionality. But it is certainly no less difficult to put multiple URIs in
ENUM than it is to register them in SIP, and I suspect, given SIP's built-in
dynamic registration capabilities, it is easier to do it with SIP. Even if
it were impossible, somehow, to register Redmond under Richardson, one could
still go get an iptel.org SIP URI and register both under that. Try it -
it's free and easy.

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.

> -----Original Message-----
> From: Brandner Rudolf [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 11:09 AM
> To: [email-masked]'
> Cc: [email-masked]; [email-masked]'
> Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt
> 
> 
> Hi Juha, folks,
> 
> the issue you are trying to get at has been discussed on the 
> list and on IETF meetings. However, the issue has not been 
> solved so far, IMHO.
> 
> You point out, that the enumservice registrations in the 
> draft are very bad, at least for SIP. You do not point out, 
> what the bad thing is. 
> 
> In your case, where you have just one SIP proxy/registrar, 
> the enumservice 'voice:sip' might not be very useful. Well, 
> AFAIK, we did not say that this enumservice is mandatory, nor 
> that it is useful in your or every case.
> 
> Nevertheless, there are other circumstances, where the 
> enumservice 'voice:sip' has its benefits and value. The 
> reason we included a way to hint that this SIP-based Service 
> would be used for Real-Time Communications whilst that would 
> be used for IM is simple; a significant group of folk that I 
> know have two different accounts - one with Redmond for IM, 
> with another with Richardson for voice. If you try the 
> Richardson account, you won't find anyone listening for IM; 
> if you try to voice-call my IM account, you won't get much 
> joy. Now...which entry do I put in my ENUM domain? Our answer 
> is both; yours is just one, as you only have one SIP-based 
> service. Having both entries gives you a hint which one to 
> use if you want to have, as an example, real-time voice communication.
> 
> To say that it's (always) a BAD IDEA to give these hints is 
> not, IMHO, proven, just because it is not appropriate for 
> some configurations.
> 
> best regards,
> Rudi
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Donnerstag, 6. März 2003 14:07
> > To: [email-masked]
> > Subject: [Enum] draft-brandner-enumservice-vovi-00.txt
> > 
> > 
> > someone pointed me to 
> draft-brandner-enumservice-vovi-00.txt, which i
> > think is a VERY BAD idea at least for sip.  the enum entry 
> of my phone
> > number would simply point to sip:[email-masked] without any 
> service types,
> > since those change all the time depending on what kind 
> > terminals i have
> > registered with the proxy of song.fi.  there are caller 
> > preferences and
> > so on that tell the capabilities of my current registered terminals.
> > 
> > is this document really somehow endorsed my the enum working 
> > group?  if
> > i remember correctly, this issue was discussed at atlanta and many
> > people shared the above view.
> > 
> > -- juha
> > 
> > _______________________________________________
> > enum mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/enum
> > 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Thu, 6 Mar 2003 22:30:25 +0000

>I wanted to make some comments about this issue.

<snip>

>makes assumptions contrary to the way SIP can and does work.

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: Michael Mealling <[email-masked]>
Date: 06 Mar 2003 18:15:09 -0500

> From my perspective, this discussion is really not about ENUM at all.
> ENUM is a system for transforming one kind of identifier into another
> kind of identifier. 

Correct...

> This is a question about how SIP is used. The
> problem is that you describe a scenario below for the usage of SIP in
> which it is preferable for users to have multiple identifiers for a
> target, each of which is associated with a different capability or
> service - it really doesn't matter whether these identifiers were
> acquired from ENUM, from a web page, or wherever. The only important
> point is that SIP is not a protocol that profits from having multiple
> identifiers sorted by the capabilities associated with these 
> identifiers. One of the primary purposes of SIP is to due away with
> the need to learn multiple identifiers for a particular user - this
> is the whole point of dynamic registration, forking, presence and
> many of SIP's other virtues.
> 
> 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).

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

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

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

-MM

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sun, 9 Mar 2003 20:44:52 +0000

>I wanted to make some comments about this issue.

Herewith my tardy response to Jon's original posting on the 'vovi' draft
(from Thursday 030306). This consisted of 4 points that are referred
to in later posts.

Point 1::
>   - ENUM is not necessarily a prerequisite for using SIP - sometimes
>   people may try to reach me with SIP without first using ENUM. Because I
>   want to make all of my identifiers available to people who use SIP
>   without consulting ENUM first (because they already have a URI, not a
>   telephone number), we cannot replace SIP registration with ENUM records
>   - we'd have to keep them in SIP as well. Provisioning multiple URIs in
>   ENUM will always have to be redundant with SIP registration. This raises
>   questions of synchronization and the usual issues that arise with
>   (undesirable) redundancy.

I understand this to mean:-  SIP doesn't need ENUM. For SIP to work at
all, identifiers must be "known" to the SIP system. Thus, for SIP, ENUM
entries are always redundant in that they merely duplicate information.
Provisioning multiple URIs in ENUM will always have to be redundant with
SIP Registration.

Response::
The above point seems to assume that a SIP UAC will not be able to
initiate a communications session to a remote destination unless
information on that destination has been registered with SIP previously
- that seems to be true only if the UAC or SIP intermediaries do not
check ENUM and act accordingly.

Also, to clarify:
I *had* read your point 1 as discussing synchronisation errors and
redundancy with SIP registrations for ENUM publication of multiple
->SIP<- URIs, but note that it actually talks of multiple URIs.

Does this point only talk to SIP URIs in ENUM, or is it instead
discussing a model where there is only ever a single URI published in
ENUM, with SIP providing the registration, storage and discovery of all
others?

----

Point 2::

>   - SIP has a built-in method for registering a URI under another URI,
>   with lots of apparatus for security, privacy, refreshes, expirations,
>   priority, capability, and so on.  Any SIP compliant (2543 or 3261) user
>   agent will support this method.  Most SIP user agents register
>   automatically when they boot or come online. I don't think we've yet
>   identified a way for applications to similarly publish information into
>   ENUM. For many applications that would be identified by ENUM (like email
>   clients or web pages) the concept isn't even meaningful.

I understand this to mean:- SIP has a mechanism for registration of a
URI "below" another. SIP User Agents use this mechanism and most
register automatically when they boot or come online. There is no such
process by which an application can update published information in
ENUM.

For many applications (like email addresses or web pages) the concept
isn't even meaningful.

Response::
Agreed; SIP is ideal for resolving real-time transient associations,
whilst the different DNS update procedures are not.

Re. 'Mechanisms by which DNS updates can be requested by applications
have not been identified'.
Well...there are ENUM Trials in Europe to explore this (amongst other
things) this. There are pretty standard (IXFR) techniques that are in
the process of being tried; it's not hard.

Re. 'not meaningful' - I beg to differ on this last. I may well have a
web page associated with my phone number - you look up ENUM to find the
URL. In fact, you could use CLI information you receive when getting an
incoming PSTN call to do an ENUM lookup and display the phone-number
associated web page.

If you mean that an email client cannot use a phone number as a source
or destination so an intermediary cannot perform an ENUM lookup on its
behalf, this is another question that is not germane to the vovi draft.
(and is also being covered in ENUM Trials, I think).

----

Point 3::
>   - SIP registrations may have very brief durations. I may only be
>   associated with a device (and hence the devices URI) for a short amount
>   of time. It isn't clear that the DNS is the best place to express very
>   short term relationships of this nature. DNS scales most effectively
>   when entries can be cached for more significant durations (at least
>   hours). SIP is optimized for real-time establishment and termination of
>   registrations.

I understand this to mean:- SIP registrations may be brief; DNS is not
the place for highly dynamic information.

Response:
Of course; that's why we expect Registrants to publish AoRs, NOT
transient contact URIs. In common for ALL ENUM entries, short-term
associations are not appropriate due to update and latency (caching)
issues.

----

Point 4:
>   - The capabilities expressed by primitives like 'voice' and 'video' are
>   both too coarse and too strict for SIP. They are too coarse because they
>   will always be redundant with SIP's own SDP-based negotiation upon
>   session establishment, which gets into far greater details about what
>   'video' entails (codecs and intervals, and so on) - if two SIP endpoints
>   both support 'video' that doesn't mean they'll be able to communicate.
>   The primitives are too strict because the SIP process is designed to
>   find the best way for two user agents to communicate, taking into
>   account the capabilities and preferences of both. Designating that a SIP
>   URI is a 'voice' URI doesn't even really make sense. If you don't need
>   this capability negotiation function of SIP, you probably don't need SIP
>   as such.

Point 4:
(i) coarse
I understand this to mean:- 'voice' or 'video' are too coarse - they do
not guarantee that a media session to carry voice (or video) is possible
between two end points, as these end points may not share a common
codec.

(ii) strict
I understand this to mean:- 'voice' or 'video' are too strict.
It is technically impossible to block an attempted registration under an
AoR based on the capability of the device making the registration (or
the AoR to be registered under the enclosing one). Thus it is incorrect
to assert that a particular AoR will be associated only with devices
that support the labelled capability.

Responses:
On "too coarse" -
Agreed - any information in ENUM is perforce redundant, and does not
guarantee media session interoperation between end points.
So? This is a label, not a guarantee.
True, we do not suggest indicating the codecs supported behind an AoR so
that an end user may try and fail to make a call, but to add enough
information to ENUM to avoid this would be fraught with problems, and
pointless, as that's what an eventual SIP INVITE will do if the SIP
entry is selected.

On "too strict" -
I repeat - there is no requirement on SIP to check the capabilities of
devices registering with a particular AoR. If an AoR is labeled as being
associated with a particular capability, and the devices registered
under this AoR either do not support that capability, or in addition
support other capabilities, then this is not a protocol problem; it's a
problem for the publisher of incorrect data.

Would mislabelling mean that a SIP AoR was not tried, even though it
DID have a device registered behind it that actually fitted another
(preferred) kind of communications session? Perhaps.

I somehow doubt that adding any text would convince, but we could add
something to state that, IF there is an entry that has a SIP AoR labeled
with 'voice' or 'video' AND there is no  entry with a pure 'sip'
enumservice (i.e. without label), AND the local client is incapable of
supporting voice or video, THEN the client may display the entry with a
SIP AoR and allow the end user to select it.
That's mighty far into local policy, but if it helps, we'll add it.

If there were to be no labelling at all, as proposed by these arguments,
then the only way that a user would know whether or not their preferred
communication session type was supported behind a given AoR would be to
engage in a SIP exchange.

This way I can get a hint in a single packet exchange, and I can choose
other sub-systems that do support my preferred communication session
type without first gleaning information on whether or not the devices
behind the SIP AoRs can support such a session type. I may miss a
possible SIP communications chance due to a mistake on the part of the
Registrant or by the Registrant's choice, but that isn't something we
can avoid or would want to avoid.

I have a perfectly adequate set of SIP phones; SIP does the codec and
address/port negotiation very well. I DO need SIP.

all the best,
   Lawrence