Subject: Re: [Enum] Questions Part 2

From: Richard Shockey <[email-masked]>
Date: Mon, 10 Mar 2003 10:09:42 -0500

>
> >
> > In the process of this discussion, I have had cause to read the 'sip'
> > draft in some detail, and to attempt to explain it to others. I'm not
> > sure I understand it fully, hence::
> >
> >  From the discussions so far, I understand that a device may register
> > with a proxy when it boots or goes online. Thus it will have its own
> > AoR; one associated purely with that device.
>
>Um, that's not what I meant, no. I have an address-of-record,
>sip:[email-masked]. When my devices (like my Cisco phone) boot, they
>all register their contact address (a device-specific URI) under that AoR.
>My AoR is not specific to that device; any number of devices may register
>there - my phone doesn't have its own AoR. I'd point you to section 10 of
>RFC3261 where the concepts of AoR and contact addresses are discussed.

For purposes of clarity ...

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.

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.

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: Richard Shockey <[email-masked]>
Date: Mon, 10 Mar 2003 16:46:48 -0500

At 02:56 PM 3/10/2003 -0500, Peterson, Jon wrote:

>Answers part 2 below.
>Jon Peterson
>NeuStar, Inc.
>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...?

We have time ..it is my hope to get all non contentious issues off the 
table first before diving into this.

I suspect this is going to be the central issue in dispute... though 
clarifying the DNSSEC text and partial E.164 resolution in 2916bis is 
second and will be at the top of the agenda.

We need to be clear on what needs to be corrected or rewritten in 2916bis 
so the authors can prepare 05 and we can immediately go to last call. This 
is the most important task the WG has in San Francisco. I think there is 
enough wiggle room here for compromise on language.

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

Which was precisely the reason for my question. Clarity on the differences 
here between H.323 and SIP CU/A will be helpful. I'm personally not taking 
a position one way or another ..only that if there is substantive 
differences or similarities I'd like the list to see those flushed out.

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

Well you see where I'm leading ... the discussion in previous messages was 
rather long with some  "philosophical" undertones. I'm just trying to make 
sure we know exactly what the issue here is and the problem the "vovi" 
draft proports to solve as well as what SIP itself addresses.

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

I understand ..believe me.

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

I understand your point, I've read the threads, but the clarity we should 
seek is practical.

Realistically .. and this is a problem of ignorance with a variety of SIP 
C/UA implementations.  We all know that I  _should_ be able to register my 
SIP IM Client User Agent with any SIP proxy ..but as an example I can only 
REGISTER with one proxy in Windows Messenger. I cannot, therefore maintain 
a corporate Windows IM account using Windows Messenger and then REGISTER 
that C/UA again to another SIP server that deals with my personal AoR and 
ultimately bind that to my personal and E.164 number in ENUM.

One of issues I see it is in the 1 to 1 relationship most SIP CU/A have 
with a proxy. This is not the case with most modern email clients that can 
be configured to handle multiple SMPT accounts.

Were SIP CU/A able to REGISTER with multiple proxy's (now I'm ignorant here 
of other products) then I could see this whole argument as less interesting 
since a single CU/A could serve multiple AoR's and there map via ENUM to 
multiple TN's.

The second issue is also practical .. given the input of a TN and the 
return of a NAPTR record with E2U+voice:sip it is also 'declares' to the 
calling party that the preference for communication is voice ..ergo do not 
even attempt to establish any other form of session since it is presumed 
that the called parties CU/A is either incapable or unwilling to accept 
sessions in any other form. That might be useful.

Make no mistake ... the single SIP AoR is preferable for any number of 
reasons principally privacy but there are some cases ...

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 10 Mar 2003 20:36:40 -0500

[snip]
> [JFP]:

> ultimately bind that to my personal and E.164 number in ENUM.

Right, but my argument is not dependent on a SIP device being able to
register its contact address under multiple AoRs (although many can). If
your SIP IM client registers under the AoR sip:[email-masked], that AoR
can in turn be registered under your personal AoR - that's what I'm saying.
The results will be the same - requests will trickle down from your personal
AoR to your NeuStar AoR, and from there to your IM client. This does not
mean that IM client needs to register itself under your personal AoR.

As an aside, note that your IM client does also have voice capabilities (if
it is indeed Windows Messenger), so the idea of ascribing a single service
like 'voice' to it is somewhat suspect.

> be configured to handle multiple SMPT accounts.

I'm not sure I would say 'most' SIP UAs have a 1-to-1 relationship. On the
FWD dialup mailing list, there has been a lot of discussion about
registering SIP clients under multiple registrars. Anyway, my Cisco 7960 is
registered under multiple AoRs right now. But again, this is not
particularly material to my argument.

> since a single CU/A could serve multiple AoR's and there map via ENUM to 

Since AoRs are stackable, a single SIP UA can be reachable under multiple
AoRs even if the UA only registers in one place. A single TN can map to the
'umbrella' AoR and reach all of the AoRs below it; there isn't really a need
for multiple TNs to map to multiple AoRs. That doesn't mean that multiple
TNs (i.e. different ENUM resource record sets) under your control can't all
map SIP enumservices to the same AoR, or to different AoRs, if you like,
though.

> sessions in any other form. That might be useful.

Well, but here's the rub: when you pass the URI from the E2U+voice:sip NAPTR
record to the SIP application, is it forbidden for the UAC to offer SDP that
contains non-voice media lines? If so, that's a significant change in SIP
behavior (in which there's no such restriction on what you can offer to a
given URI), and it moreover assumes a tightly-composed architecture for your
DDDS resolver and SIP client. I think enumservices should work even if we
assume that the rewrite is passed to an application that is decoupled from
the resolver (granted that of course, the resolver must know what
enumservices it's looking for).

Once someone learns a URI through ENUM, they should be able to do anything
with that URI that they'd be able to do with it if they read the URI on a
web page, in my opinion. Otherwise ENUM becomes something more oppressive
than just a directory service.

If you have a preference for voice communications, that preference can be
enforced by the SDP answer of your user agent server in a much more powerful
manner. There are also means by which it can be enforced by your proxy
server (though with less strict controls). It can even be enforced (to a yet
more limited degree) by certain structures that appear in the URI you
acquire from ENUM. But the UAS and proxy have a real-time awareness of your
current capabilities that ENUM, and the data it contains, will not
realistically possess. I would argue that this flexibility and real-time
responsiveness is even more useful than labels, and that short-circuiting
SIP with stale information in ENUM is harmful. This harmfulness can cause
communication attempts to fail that should succeed, and does not prevent
effectively unwanted communication attempts, as I've illustrated in
practical examples in this thread.

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Wed, 12 Mar 2003 01:50:18 +0000

Hi Jon, Michael, Rich, Folks,

OK - internally incoherent, the assertion that ascribing only one
service to Windows Messenger is suspect when I still can't get my
******* iMic to work with VirtualPC and Windows Messenger so it IS
only capable of handling IM, and finally that a SIP UA does not
behave as the 'vovi' draft would like it to - I'll bite.

There are two options when an entry has a Teleservice Label.
Either:
The label is purely an item "for display" that is presented to an end
user when they "break the tie" in a DDDS round with no further action or
interpretation on the part of the DDDS client program,
Or..
there is some mandatory feature, in which case the DDDS client will NOT
present an entry that is so tagged if either the end user has
pre-specified that they are not interested in this teleservice, or the
local equipment is incapable of supporting the tagged teleservice.

     In the latter case there ARE some real issues, and we have been
     discussing the minutiae of these for some time. My reason for exploring
     these (at some length) is that several groups out in the R.W. have
     suggested that an end user might be allowed to pre-select the
     teleservices they're interested in with a "user-friendly" ENUM client and
     provisioning systems, in which case any entry that isn't identifiable as
     being tied to a teleservice or that isn't tagged with some teleservice
     label will be discarded.

     Whether I think it's a good idea or not, I believe that these clients
     will be released simply because the marketing folk think that "Joe
     Punter" just about understands 'voice' or 'video' or 'fax' or 'email' or
     'sms' but that plain 'sip' is going to look like 'pandora's box'; it's
     going to be hard to explain that this is a special case, and you can't
     know in advance what you're going to get.

     Will such a filtering system have odd side effects? - quite probably and
     it's something I've been trying to get my head around, with Jon's help.

     This is made more fun by working out how to explain that you only need
     one AoR and Mr. Punter should combine them with iptel.org, or that a
     Telecomms group in a company is not going to be in a turf war (with
     different preferred suppliers) from the IT group, and that they shouldn't
     both be arguing over who gets to control the ALG(s) and who has to
     open what pinholes on whose say so.

     However, back to 'vovi'...

In the former "permissive" or "soft hint" case we originally envisaged in
"vovi", the labels are not used to filter entries where an end user has made
some pre-selected choice or where local equipment is incapable of handling
the tagged teleservice.

The end system may still filter out those protocols that it cannot
handle, of course, so some tagged entries may not be presented for other
reasons.

Also, the end system MAY use the labels (or lack of them) to highlight
or sequence presentation of the entries to the end user; this is purely
a matter of local implementation and not subject to protocol
standardisation as it doesn't affect DDDS operation.

I think that, in this case, the beef seems to be that the label, when
tagged to an entry that uses the SIP protocol, may not be valid or
useful. An AoR is not intrinsically associated with any teleservice. The
argument would seem to be that the IETF should not condone indications
that are (or may be) invalid.

The counter-argument is that the label can be argued to be purely a
matter between the Registrant and the End User, with the "ENUM protocol"
merely carrying this data. Thus the validity or otherwise (or even the
sense in labelling an entry) is not a protocol issue. The Registrant
could equally label an entry "pink" as far as DDDS is concerned.

The AoR MAY happen to be associated with a teleservice only by
administrative (non-technical) means, but that is an issue for the
Registrant who applies the label and registers their presence with SIP
devices of that given capability, not of SIP infrastructure or of ENUM
and the DDDS client.

If the Registrant labels an entry, then they SHOULD ensure that devices
capable of supporting that teleservice are available "behind" that AoR,
so that the standard negotiation mechanisms will resolve to the
indicated service.

That is what was meant in section 3.2 and 4.2 (albeit stated that
offering other services SHOULD not happen). The SHOULD NOT was intended
to occur purely because the Registrant had arranged for the labelled
teleservice to be supported. The onus is on them to register devices
that support the labelled teleservice. If they don't, then the ENUM user
MAY be offered another type of communication, as it says there.

Given that there is no impact on "ENUM protocol" operation, you know
which way I would move, were I voting in this County today.

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: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Mar 2003 05:55:52 -0500

Feeling somewhat Energizer-rabbit-like but, more within.

Michael, I'd appreciate it if you would comment on the first issue.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Conroy, Lawrence (SMTP) [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2003 5:50 PM
> To: Jon; Michael; Rich
> Cc: [email-masked]
> Subject: Re: Questions Part 2
> 
[snip]
> local equipment is incapable of supporting the tagged teleservice.

Well, let's be more specific. A 'teleservice label' is part of the string
that constitutes an enumservice. Enumservices are not 'hints' - they are
literal strings, and either you match them or you don't. DDDS is quite
specific about this matter. So I guess the first of your two options above
is immediately disqualified... or is it?

I think the text in rfc2916bis 2.6 could appear to qualify this point in its
description of an 'intelligent' resolver. Essentially, the intelligent
resolver text clarifies the meaning of Step 4 of the DDDS algorithm a bit,
in so far as it suggests that the process of selecting Rules based on
service may involve GUI calls, etc. However, I didn't take 2.6 to mean that
enumservices themselves were ignored at the client's discretion. I'm not
sure that it means that "intelligent" resolvers have no list of supported
enumservices, and will thus display all NAPTR records to the user's GUI
regardles of enumservice. Tie-breaking is one thing - that's a reasonable
justification for a GUI event. But I've heard some other things in this
thread that I'm not so comfortable with - like the idea that client that
supports only SIP IM, say, might decide to try to use an 'E2U+voice:sip'
enumservice, presumably based on some GUI selection. In that case, the GUI
makes enumservices meaningless - it might as well just hand all the URIs
over to the user and let them choose irrespective of enumservices.

Even with the most generous interpretation of 2.6, I think that enumservices
should be required to function for either an "intelligent" resolver or a
"dumb" resolver. After all, the author of NATPR records has no way to
anticipate whether clients that ask for records will have intelligent or
dumb resolvers (ENUM is a public resource that anyone can access - it isn't
constrained to an environment in which you have some assurance that all
resolvers are smart). If there are problems with these enumservices for
"dumb" resolvers, I think that's a problem for the whole proposal.

Michael?

>      know in advance what you're going to get.

This is the IETF. We make standards. You have proposed a standard to the
IETF that uses these labels. People out in the R.W., including marketing
folk, are empowered to build ENUM products using whatever they like,
including Limburger cheese. If we don't standardize these things, the sin is
not on our head, anyway.

>      it's something I've been trying to get my head around, with Jon's
help.

Glad to be of service.

>      open what pinholes on whose say so.

[As an aside - Actually, in my explanation of the example of Telecomms and
IT I was very specific that firewall traversal is unchanged by the manner
that URIs are composed in SIP. I don't know any simpler way to put it. If
you go to IT, and they redirect you to Telecomms, the request will approach
all of Telecomms systems, including their firewalls, just like any other
request to Telecomms from the outside world. This does not raise any
questions about control of firewalls or ALGs - that stays exactly as it is
now.]

> standardisation as it doesn't affect DDDS operation.

Right, I think I understand what you mean, though this is a greyish area for
DDDS and ENUM, as I discuss above.

> that are (or may be) invalid.

That's a big helping of the beef, anyway. Enough to chew on for one mail.

> could equally label an entry "pink" as far as DDDS is concerned.

Well, of course the DNS just carries this data - ENUM queries return what
has been provisioned. Agreed that users could provision the
"E2U+cheese:limburger" enumservice in a NAPTR record, they just shouldn't
expect anyone to be interoperable with it because it's unstandardized. Users
can also put 'mailto' records for [email-masked]?Subject=@!%&?'
in their NAPTR records, they just shouldn't expect to get any mail.

I could take your argument to be that we should standardize the "vovi"
labels on the grounds that people should be able to provision whatever they
want in ENUM anyway. Or does this have any bearing on whether or not to
standardize a label? More below...

> devices of that given capability, not of SIP infrastructure or of ENUM

The fact that when you apply a label to an enumservice, registrars shouldn't
accept certain registrations is not a SIP infrastructure issue? The fact
that when I acquire a record using one of these labels, my UAC should
constrain the media types I offer is not a SIP infrastructure issue? Hmm.

If we give people tools that make it easy for them to make mistakes or
misunderstand the interactions of complicated sets of systems, we shouldn't
be surprised when interoperability doesn't flourish. Pushing the
responsibility for all of this on the end user, and making it their mistake
if they use SIP normally, doesn't seem attractive to me.

This also begs questions about the distinction you raised two paragraphs ago
- the distinction between the Registrant and the End User. Is the user who
provisions a record in ENUM that points to a given SIP URI also
-necessarily- going to be the same user who controls any and all devices
that might register under that SIP URI? There are numerous cases I can
imagine in which that might not be the case. Some SIP AoRs represent groups
instead of particular users, for example. Anyway, it's all well and good to
say that he who provisions ENUM shouldn't take incompatible actions in SIP,
but they needn't necessarily be the same bloke.

> so that the standard negotiation mechanisms will resolve to the

Well I agree, if the "vovi" enumservices are used they better ensure it -
and that goes for devices that register under the URI, registrars that
accept these registrations, and devices that offer requests to the URI.

In the absence of the teleservice label (using the "E2U+sip" enumservice)
these sorts of questions just don't arise. 

> MAY be offered another type of communication, as it says there.

Obviously, in the context of your proposal I think this is good advice, the
question is whether or not it's enough.