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

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 10 Mar 2003 05:03:08 -0500

Okay, another helping.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Conroy, Lawrence (SMTP) [mailto:[email-masked]]
> Sent: Sunday, March 09, 2003 12:45 PM
> To: Peterson, Jon; Richard
> Cc: [email-masked]; Rudi on the road
> Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt
> 
[snip]
> 
> Point 1::
> 
> 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.
> 

This is orthogonal to whether or not SIP "needs" ENUM (which it does, when
you have a telephone number and want a SIP URI). For SIP to work, SIP device
URIs should be known to a SIP registrar, sure. Any AoRs you'd want to put in
ENUM should be available to ordinary SIP clients that use URIs rather than
telephone numbers. For that reason, this sort of provisioning in ENUM would
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.
> 

Right. So when do you check ENUM? When you have a telephone number and you
want a URI. Well, what if you don't have a telephone number? What if you
have a SIP URI?

If an end user wants to be reachable through multiple SIP devices, they want
to be reachable through them in the same way regardless of whether or not a
caller only knows a telephone number for them, I think. ENUM shouldn't have
to be a prerequisite for discovering all of the SIP AoRs or devices through
which users are available. If we architect enumservices that assume that SIP
is never used unless ENUM is used first, that's bad.

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

I meant SIP URIs, sorry.

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

No, I'm only talking about SIP here. This text points out that if you do not
adopt a model in which a single SIP AoR is published in ENUM, you are left
with the resulting ENUM-SIP synchronization problem, which is exacerbated by
points 2 and 3.

> ----
> 
> Point 2::
> 
> 
> 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.
> 

Well, I have no doubt that there are candidates for this. But these methods
have not yet been identified as IETF standards for ENUM. I haven't seen a
proposal in this WG yet for anything, I don't think. IXFR might turn out to
be controversial (though let's not go there now!). RFC2916 was released
without any way for applications to register themselves in ENUM (and I doubt
this will come to be in scope for bis). RFC2543 was released with a REGISTER
method. It just shows a different orientation of the standards; SIP was
designed with dynamic registration in mind. I would say that the SIP
community is a lot further along on registration than ENUM is.

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

'not meaningful' here signifies only that the web and email are not
real-time communications in the sense, say, that instant messaging is. A web
page does not disappear here and reappear there five times in an hour, all
the while dynamically updating some directory service to point to its
current location. Web and email URIs are comparatively static resources.
Therefore the relatively static nature of DNS is not impactful to their
registration.

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

No, I didn't mean that.

> ----
> 
> Point 3::
> 
> 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.
> 

Seems like ample justification to recommend against putting contact
addresses in ENUM.

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

Yes, this would beg the question of how effective a 'label' is, and what you
hope to accomplish by supplying a label.

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

Agreed, it would be terrifying to put further capability information into
ENUM. But 'voice' is a slippery slope. It doesn't accomplish enough on its
own to be able to determine that you'll be able to communicate before you
call the URI, and yet we can't realistically supplement it with further
information.

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

No, it just illustrates that your enumservice concept is incoherent. If
putting a URI in ENUM would make some SIP registrations 'incorrect' or
incompatible with ENUM, then there's something wrong with the way we're
using ENUM. ENUM is a way of turning telephone numbers into URIs; it should
change the significance of those URIs in their native protocols.

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

Yes, and that would be bad!

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

Well, this is the DDDS compliance issue. Enumservice strings are literals -
there's a list of them that are supported, and everything else is
unsupported (as far as I understand DDDS), for a given client going through
the algoirthm. So if a client has only IM capability, why would the DDDS
algorithm ever return rules with 'voice' and 'video' in your case above? It
would only do so if the client was looking for them, right? I don't think
there's a DDDS concept of 'give me any old enumservice with the string *sip*
in it'.

But if a client looks for SIP-specific records regardless of its capability,
then why not just have an 'e2u+sip' service and do away with this complexity
and the resulting negative effects?

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

Again, just seeing 'video' in the label doesn't mean that the remote device
will support the same sorts of sessions that you do - you still have to send
a SIP request in order to do SDP negotiation to see if compatible codecs are
available. So you still need a SIP exchange to see what is supported behind
the AoR.

On the use of the term 'mistake' to characterize the IM-under-voice:sip
example, I think it is an open question whether the mistake lies in
registering a device with an 'incorrect' capability under a given AoR, or in
using a service-specific enumservice in the first place. No registration for
an extent URI is ever 'mistaken' in SIP. I think it would be nice if we
could define enumservices for SIP that did not raise the possibility of
turning registrations into mistakes.

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