Subject: [Enum] VOVI draft 'voice:sip' enumservice

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Fri, 7 Mar 2003 12:28:44 +0000

FYI - sent already to your on the road account, enum, and the rest of
the crowd.
----
Hi Folks,
   (Thread re-named - I assume that this is the issue ?)

How does the enumservice 'voice:sip' in the vovi draft break SIP?
I'm bemused, as it works for me - I've used it.

My SIP hard 'phone is a single function device; it can be plugged in
pretty much anywhere and registers itself with a SIP Service Provider.
In the "real world", for some of the voice services provided, they
expect to be paid. As Scott Petrack discovered, "the IETF doesn't do
Business Relationships", so consider this an aside to explain why I
have two service-specific accounts.

My VirtualPC fires up and handles only IM - it doesn't have a microphone
connected so it doesn't support RTC. It registers itself with another
SIP Service Provider; this fine bunch don't have my credit card info.
Until I can fathom out how to get a microphone and RTC working in
VirtualPC, the capability of the device(s) behind this SIP registration
is not going to change soon either.

These *ARE* single function devices - whilst there are a lot of people
"out there" with multi-function devices (e.g. .NET Messenger with RTC
and IM support), those of us with hard 'phones have a defined service
profile; this will not change short of re-flashing the 'phone. This is
not a highly dynamic entry, at least not anytime soon.

Note that even if I register several 'phones with the same AoR, they're
all just voice terminals. I had thought that what goes into ENUM is the
AoR, not the individual contact URIs. However, I've been convinced that
a contact URI would work as well; I learn.

Thus, if you try to IM to this 'phone, you will waste your time. It
doesn't support T.38 so you can't fax to it - it just does voice. If I
as a Registrant want to give a hint that you will only be successful if
you do an INVITE with a voice media offer, then I can't see how this
breaks SIP, or is even unhelpful.

If any ENUM client wants to treat 'voice:sip' -as if it were- 'sip',
that's fine. Support for this enumservice consists solely of ignoring
the hint and treating it as a standard 'sip' enumservice.

Of course, anything to the account I have registered my 'phone with other
than an INVITE with a voice media offer will be rejected . The 'phone
fully supports 3261 but does not engage in all possible (non-media)
sessions. It's a 'phone.

Similarly, if anyone wants to try to INVITE my Virtual PC to a voice
session, it will be rejected. It's also 3261 compliant, but only handles
an IM session, due to my incompetence.

Now, if anyone thinks that giving this hint is a BAD choice on the part
of the registrant, that's a valid opinion, and there are many privacy
issues with ENUM that we need to spell out (not just in this draft) so
that folks can make informed choices on the information they publish.
No-one is forced to publish information that they don't want the world
to know - we have the 'I'm not telling you any more information here'
enumservices as well.

I still don't understand how this draft is not aligned with IETF
standards, specifically 3261. I'm willing to believe that SIP with
CallerPrefs could allow a client to negotiate a kind of service;
I'm a little surprised that support for this is REQUIRED as the only
solution if we're to avoid extended offer/rejection cycles.

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: Sun, 9 Mar 2003 00:58:21 -0500

Quick summary:

As far I can tell, you are not phased by the first bullet point from my
original mail, in which I maintain that service-specific enumservices can
obstruct communications attempts that should succeed - instead, you're
suggesting that SIP be constrained in certain ways in the environment that
"vovi" is deployed to prevent this from arising. Although your mail focuses
more on AoRs than contact addresses, there is still a suggestion below that
we should not counterindicate the appearance of device URIs in ENUM, even
though you seem to agree with the substance of my second and third bullet
points, which show why this would be problematic. I haven't seen any
response of my fourth bullet point, which raises concerns about the
granularity of concepts like 'voice' when compared with SIP capability
negotiation. I think I've been able to substantiate ways in which these
enumservices entail changes to SIP behavior. Finally, there are plenty of
issues we haven't even begun to discuss, like the considerations surrounding
multiservice clients, or privacy. I think there are still substantial
technical objections on the table.

More below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Conroy, Lawrence (SMTP) [mailto:[email-masked]]
> Sent: Saturday, March 08, 2003 5:56 AM
> To: Peterson, Jon; Richard; Rudi on the road
> Cc: [email-masked]
> Subject: [Enum] RE: VOVI draft 'voice:sip' enumservice
> 
> 
> Hi Jon, folks,
>   Thanks for the useful points - I think that they help to zero
> in on the problem - without which we can't fix it.
> 
> Herewith my response - I apologise for quoting all of Jon's text
> below, but these ARE important points that should be read in
> conjunction.
> 
> ============
> I think that the key points here seems to be the use of contact 
> addresses, and assumptions that there is some protocol feature 
> required to check that an avowed Registrant policy is being enforced, 
> and that the ENUM client MUST follow the hints published. My bad, as 
> none of these these are intended in the VOVI draft.
> 
> In the VOVI draft, there is NO protocol feature proposed or required 
> of SIP. There is NO check that, if an end user says that this account 
> is associated with RTC, all of the contacts represented by this AoR 
> ARE capable of RTC. The end user can make a mistake or lie and 
> register one kind of device "under" an account that they tell the 
> world is actually associated with another kind of service.
> 

It doesn't propose features for SIP, it (inadvertantly or no) entails them.
Architecting a system in the way that the "vovi" draft suggests leaves you
with little choice other than to make the sort of changes I was detailing,
if you want the behavior of the system to be coherent.

> It seems (to me) perfectly valid for a SIP subscriber to choose to 
> register an IM device, for example, under an account that, ->in 
> ENUM<-, is shown as being associated with only voice teleservice. 
> This means that SIP users (who have the URI already containing this 
> AoR) may negotiate any supported session (including IM), whilst those 
> using ENUM will normally only select this account if they intend to 
> place a voice call.
> 

Valid in what sense? Surely not the sense 'desirable'. These enumservices
obstruct attempts to communicate that would ordinarily succeed.

> At the extreme, there is no compulsion on a Registrant to install a 
> NAPTR referring to a particular SIP account at all; thus ENUM users 
> won't use that account, whilst SIP users who have the AoR will 
> continue to use it. IMHO, this doesn't break either SIP or ENUM. I 
> assert that ENUM is a pure opt-in service and the Registrant is free 
> to select the information they wish to publish in it (and the 
> information they choose NOT to publish). SIP is no different from 
> other information here.
> 

Nothing I disagree with here - but this doesn't seem to argue either way the
matter at hand (the syntax of SIP-based enumservices). All of the above
should be true regardless of what enumservices we choose to standardize. We
both want ENUM and SIP to play together, the only question is what approach
we adopt.

> The label that a particular account and its AoR is associated with 
> one kind of service is a hint that a Registrant MAY choose to put 
> into ENUM, and that the querying program MAY choose to present to its 
> end user or to act on if the end user has pre-specified their policy.
> 

Well, be careful here about that second MAY. I think ENUM and DDDS compel
you to evaluate enumservices in a very specific way. Saying that the ENUM
querying program MAY choose to present a service and URI to an end user or
communications application is one thing - much more important is whether or
not the application asks the user, before it queries ENUM, 'what kind of
sessions are you looking for, enter one or more of of: voice, video, im?' or
something. If you assume that you are only looking for voice, that leads to
the restriction of options - the DDDS algorithm doesn't present the user
with ENUM options for unsought enumservices. I take it you envision that
your application will look only for some enumservices and not others (based
on the capability of available communications applications) - if you
envision otherwise, that's a DDDS compliance issue.

> The Registrant MAY instead choose NOT to give a hint that a 
> particular subset of communication session types may be associated 
> with a particular account and AoR; in this case they just use the 
> "pure" sip enumservice. Apart from the hint the information presented 
> is exactly the same.

If there were not mandatory DDDS behavior associated with it, I would be
more comfortable calling the enumservice name a 'hint'. As it stands, it's a
mandate. If I don't recognize or support the enumservice I can't use it.

> 
> Similarly, the querying end user's program MAY choose to ignore a 
> hint within a NAPTR and treat this as a standard SIP account capable 
> of negotiating and initiating any communications session; they can 
> treat this NAPTR as if it were a standard 'sip' enumservice.
> 

Well, the program doesn't 'ignore' hints - the DDDS algorithm tells the
program how to evaluate enumservices. This is why it is significant how the
enumservice string is strcutured, and what criteria the application uses to
determine which enumservices are valid. I don't think applications are
permitted by the ENUM standard to ignore the DDDS rules.

> There is no compulsion here, either to publish a NAPTR with a hint as 
> to the service expected from this account or to use this hint when 
> receiving the NAPTR. Nothing is mandatory.
> 

Again, there is a compulsion to use the hint when receiving the NAPTR, as
I've said. There are plenty of mandatory statements in RFC340x and
rfc2916bis to this effect.

> It is equally possible for a determined Registrant to put a contact 
> URI into either a NAPTR with 'sip' enumservice OR with a 'voice:sip' 
> enumservice; it's dumb, but I trust we don't expect a DNS Service 
> Provider to check somehow before publishing the domain data in DNS in 
> these cases.
> 

Well, I agree with you there. It is within our power, however, to recommend
in IETF standards that users do not put contact addresses for SIP into ENUM.
The "vovi" proposal, as far as I can tell, entails that contact addresses
are used (or, worse, constraints are applied to SIP). It would seem to be a
strong recommendation in the opposite direction. I would prefer that we not
put device-specific URIs in the DNS, and I have offered significant
arguments to the contrary, arguments which, again, I do not think are
contested here.

> ----
> 
> I agree that when an AoR is installed in a NAPTR it does not 
> intrinsically have any teleservice capability associated with it. The 
> teleservice capability of the end systems registered "behind" that 
> AoR defines the communications session that may be negotiated via 
> this account.
> 
> I'm willing to believe that communication session type can be 
> negotiated within the SIP process once it has begun, and that 
> starting the SIP process can expose the teleservice capability of end 
> units associated with an AoR in a controlled manner.
> 
> I agree that if a particular account is associated with a set of end 
> systems that have varying capability then the use of teleservice- 
> specific hints associated with the AoR is inappropriate, due to the 
> intrinsic latency in updating DNS and so the ENUM data being "out of 
> date".
> 
> However, for those cases where (i) an AoR is associated over the long 
> term with a set of end systems that have only a single function, and 
> (ii) the Registrant chooses to register only devices that have a 
> specified teleservice capability under this particular AoR, then 
> giving a hint to this capability within ENUM seems (to me) to be both 
> possible and may be useful *TO A QUERYING END USER*.
> 

Well, here's the thing. As I said in my original note, "vovi" works when you
have one SIP enumservice in your ENUM resource record set expressing one
capability - I'm not questioning that. Whether or not it's actually more
beneficial to the end user than using the 'sip' enumservice, however, is
arguable, since if there were one 'sip' enumservice in stead of one
'voice:sip' enumservice, then the same behavior would result (i.e. you only
get back one record, and you use it). In the single record case it is no
more useful to a querying user as far as I can see, and possibly less useful
if the querying user would rather communicate in some other way, and the
"vovi" record erroneously suggests that it would not be possible.

But anyway, the real problems arise when you have multiple ENUM resource
records containing SIP URIs, especially when they're advertising different
capabilities. This was the thrust of my argument and objections in my
previous note. This was the use-case that Rudi brought to the table that
sparked this thread (one AoR for 'voice', one for 'im'). I think this is
where the 'value' in having service-specific enumservices arises, and it's
also where you start to have problems.

Moreover, I think that in order for the 'voice:sip' enumservice not to cause
problems, the constraints (i) or (ii) above need to be enforced somehow, and
this is a SIP behavioral change. It's not enough that you say an AoR tends,
over the long term, to have UAs with only one capability registered under
it. That's true of my FWD AoR, but I might decide to register IM there at
any moment, and quite fleetingly. The point is that these enumservices
constrain user behavior for SIP registrations, and either users have to
remember that they are so constrained, or that constraint needs to be
enforced programmatically by SIP registrars. Both seem unnecessarily
inflexible to me, especially given the presence of an alternative that does
not require this (i.e. the 'sip' enumservice). No matter how you slice it,
this entails changes to SIP behavior because of the choice of enumservice.

> If a SIP UAC is all that will process ENUM data, then as pointed out 
> there is little need for ENUM as the end user may have a SIP URI 
> already, and any data in ENUM is intrinsically redundant.
> 

Well, no. ENUM lets you turn a telephone number in to a URI - if you're
SIP-capable, then potentially into a SIP URI. That's a tremendous value, and
there's plenty of need for ENUM. Having a telephone number doesn't give you
any idea how to reach a resource on the Internet. That is the problem that
ENUM solves, and it's a very important problem. So I don't think that just
because SIP shouldn't use ENUM to negotiate service-specific capabilities,
ENUM is somehow useless to SIP.

That much said, I agree that the redundancy of provisioning contact
addresses in ENUM and provisioning contact addresses in SIP would be
troublesome, though, for many reasons given in my original  note.

> However, I suggest that there could be other programs that query, 
> receive and process this information. The "Generic ENUM Client" is an 
> example of a program that can process the returned results, possibly 
> display them to an end user so that they select a particular option 
> and so "break the tie" in the DDDS processing round, and then fire up 
> the appropriate communications program with the resulting URI.
> 

Right, I understand the application you have in mind, I think. I'd refer you
to rfc2916bis-04 section 2.6, just to make sure we're on the same page about
how DDDS works, especially regarding tie-breaking. Your concept is allowed
by 2.6 in my reading, though with some important caveats.

> That program may well be a SIP UAC; however, the SIP UAC will not 
> have checked ENUM at all, as this has been done by an external ENUM 
> client.

Sure, the resolver may be discrete from any particular communications
application. bis section 2.6 discusses this as well.

> 
> In the specific case of a NAPTR with 'voice:sip' enumservice, it is 
> possible for the Registrant to lie, indicating an account that only 
> has devices registered "behind" the AOR that do not support voice. 
> The end user's SIP UAC will fail in its attempts to initiate a voice 
> call.

Sounds more like a mistake than a lie. But agreed that this is possible;
this is a less-harmful corollary of the problem I brought up in my previous
mail.

> Will the end user be unhappy? - possibly. Is this a protocol issue? - 
> I don't think so. If it were, then we'd need protocol mechanisms to 
> block someone putting an incorrect MX record or even an incorrect SOA 
> record into DNS. Equally, we'd require a Telephone Service Provider 
> to check that an entry in the White Pages that indicated a Fax 
> machine really DID have a fax machine plugged in.
> 

Misprovisioning problems that are comparable to bad MX records and whatnot
exist irrespective of enumservices. I can mistype a URI for SIP, leading to
a nonsensical result, whether I use 'voice:sip' or 'sip' as my enumservice.
I don't think this helps to decide between the two enumservice alternatives
in any way.

Anyway, my version of this problem (in which an IM client registers under an
AoR attributed to a 'voice:sip' ENUM record) is a protocol issue created by
the 'voice:sip' enumservice that does not exist for the 'sip' enumservice. I
don't think it's really comparable to this. This would be more like if you
had MX records that were specific to the capability of some mail client
(like Eudora versus Outlook) and insisted that you'd make sure somehow that
people only used the right client to retrieve emails.

> It would seem that these applicability points are not clear in the 
> current draft. Given that these can be spelled out in the "other 
> information that the authors deem useful" section of the 
> registration, is there still an objection on technical grounds (i.e. 
> why won't it work?).
> 

Unfortunately, from my perspective, you haven't answered my objections by a
long shot, and I don't see any easy path to addressing them for "vovi". I
don't think an applicability statement could resolve this concern. See the
summary at the start of the mail.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

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

inline.

Jon Peterson
NeuStar, Inc.

> Sent: Sunday, March 09, 2003 12:13 PM
> To: Peterson, Jon; Richard; Rudi
> Cc: [email-masked]
> Re-reading the response from Jon to my re-named thread 
> posting, I feel that
> a more point by point reaction may help - my more general 
> response seemed to
> leave exactly the same misunderstandings that I was trying to dispel.
> 
[snip]
>
> 
> I summarise this as:'If an IM-capable device registers behind an AoR
> that is labelled with 'voice', then an end user, when retrieving the
> published ENUM data, will not choose that AoR if they have a SIP client
> that is only capable of IM. This is breakage for SIP'.
> 
> It is true that the end user might assume that they are incapable of
> contacting a Registrant using this SIP AoR, but that may be the
> intention of the Registrant in publishing the information in this way;
> they are, in effect, stating that they only want voice calls via this
> AoR.
> 
> A SIP UAC is still capable of contacting the Registrant's SIP UAS,
> *IF THEY ALREADY HAVE THE AoR*, so this does not break SIP.
> To summarise, it still works fine.
> 

Well, to this last point, I think you understand what I'm saying, but your
analysis ignores the consequences of this. Of course if someone already
possesses the SIP AoR, they can use it normally. If they already possess the
AoR, they don't need to be using ENUM to discover a SIP URI, right? The
people for whom SIP is broken by your enumservice are the people that are
using ENUM because they don't already possess the AoR - because they only
have a telephone number. The point is that using ENUM with "vovi"
enumservices potentially blinds them to the capabilities of devices
registered at the AoR. Your point here amounts to "if you don't use ENUM,
then the "vovi" enumservices won't affect your SIP behavior." 

To the second point, if the ENUM registrant hopes to somehow prevent
non-voice media streams from being offered to the endpoint, then as I've
illustrated before, this enumservice architecture will not prevent that
unless you further assume further breakage of SIP - that is, unless you
assume that the SDP offer will only contain voice-related codecs when the
enumservice that resulted in the SIP INVITE was 'E2U+sip:voice'. That would
be a serious SIP functional change. In other words, putting 'E2U+sip:voice'
in the DNS will not in any way constrain SIP UACs from offering non-voice
media lines to the URI in question.

And finally, to the first point, it's not just a matter that an 'end user
might assume they are incapable of contacting' the target - this is a DDDS
question. If you support only IM, you look for an 'E2U+im:sip' record, or
something, and it's not there. If the only capability the client possesses
is im, it will not look for 'voice' records - I'm not sure how else to
understand the "vovi" proposal. If the client is willing to get a 'voice'
record even though it only supports IM, then essentially the 'voice' part is
ignored - in which case you might as well have used an 'E2U+sip' enumservice
for all the good the 'voice' does you, and you very well may be breaking
compliance with DDDS.

[snip]
> 
> 8-()
> 
> It does not require any policy constraint on the part of the SIP
infrastructure.
> If a Registrant chooses to SIP register a device that is capable of
another
> service than the one with which the AoR is labelled in ENUM, then they may
> intend that information on this capability is not published in EMUM.
> They may have made a mistake. In either case, this does NOT top SIP UACs
> working, nor does it require a change to SIP Registrar operation of any
kind.

My response to this can be found above.

> We do not believe that publication of contact addresses is appropriate in
ENUM.
> You continue to believe that we are actually proposing this, despite our
> protestations to the contrary, as you think that to do otherwise would
> require policy changes to SIP infrastructure to exclude inappropriate
> registrations against an AoR that was labelled with a 
> particular capability.
> 
> All I can do is to re-iterate our statement that AoRs are the only
appropriate
> SIP entities to publish in ENUM, due to their long-term nature.
> 
> Given the nature of ENUM, it is not possible to block a Registrant from
> publishing a contact address (or some AoR with which, for some reason,
> they have only a momentary association and then discard forever).
> We just don't think it's a good idea for the often repeated DNS update
> latency reasons.
> 

The difference between our positions here, I think, is that I want the
standard to offer some guidance about the matter. Your statements that it is
not possible to block a registrant from entering a contact address is
orthogonal to what we recommend in the standard. If we show people why this
would be bad, and tell them not to do it, it will help. It is also possible
to run IP over HTTP, but we recommend against it in the IETF and tell people
why it is bad.

[snip]
> 
> My reasons for having two accounts, each of which I use for registrations
> of teleservice-specific devices, is administrative (i.e. non-technical)
and
> so not the subject of standardisation, except insofar as I am not allowed
to
> do this by a draft including such labelling being blocked by the IETF.
> 
> I understand that I could combine the two accounts under a third, or to
> register one account under the other. In so doing, the resulting "top"
> account would no longer be teleservice-specific, and so it would be
> inappropriate to label it so.
> 
> However, I contend that it is perfectly possible to have two accounts
> and to use each one in a service-specific manner, and thus being able
> to label each one accordingly is appropriate. If others do not make this
> choice but instead decide on a single multi-capability account or simply
> choose not to label the entry, they won't have a use for a service-
> specific label and so will use the entry without it (i.e. use a "plain"
> 'sip' enumservice).
> 
> I don't see how that means that my choice, and wish to indicate which
> account I would like folks to use for voice calls, is unacceptable.
> 

Sure, it is possible to choose to have two service-specific AoRs. It defeats
the whole purpose of the discovery and capability negotation aspects of SIP,
but it's possible. It basically means that people who don't use ENUM need to
remember two different AoRs for you, depending on what service they want to
use. Remember, ENUM is used when you have a telephone number. Unless you
mean that SIP users should NEVER distribute SIP URIs for themselves, but
should ONLY distribute telephone numbers, in which case they would only have
to remember one identifier. Which would, once again, be a change in how SIP
works.

All that said, let me pose you the question underlying the capital-"P"
Problem again (the one in the email I don't think you've answered yet):
what, exactly, is the point of a policy that prevents composing URIs in SIP,
but instead composes them in ENUM? What does the SIP policy of having two
service-specific AoRs try to prevent that ENUM does not enable?

It isn't clear what composing this two service-specific AoRs in ENUM
accomplishes because:

- People can still send requests to your 'service specific' URIs that offer
other services in SDP.
- In my IM-under-voice:sip case, it blocks requests that should succeed.

If there's some other policy objective that you hope to fulfill by having
two service-specific SIP AoRs, it would really help if I understood what
that was.

> BTW, I'm not sure how your bullet 1 on provisioning multiple URIs in
> ENUM causing synchronisation issues that arise with (undesirable)
> redundancy fits here as these are long-term (and so stable) AoRs?
> 

My bullet 1 point is applicable to the Problem question I pose above.

[snip]
>
> 
> Again, if by my purely administrative actions I have two accounts, one
> I use exclusively for voice capable SIP registrations with the other
> that I use exclusively for IM capable SIP registrations, how does that
> state that I must mean that I'm installing contact addresses? The AoRs
> have no intrinsic technical service capability associated with them
> OTHER than that I assert by my administrative actions. I repeat, I am NOT
> suggesting the use of SIP contact addresses in ENUM.
> 

Okay, I won't come back to this point.

> I was reminded that it would be possible to publish contact URIs in ENUM;
> OK, it is possible for someone to do this. We all agree that this is a bad
> idea as you quite correctly point out that contact addresses may be short
> term.
> 

Possible, but we can counterindicate it.

> 
> If a Registrant chooses to label a SIP AoR with a hint as to its use,
> and I as an end user choose to ignore this advice, then there is no
> enforcement other than a SIP rejection.
> 

Yes, but you thus agree that labeling a URI with a service-specific
enumservice doesn't prevent anyone from launch SIP requests offering SDP
with other services, right? So what is the policy you're enabling here with
the ENUM labels?

> Outside of California, I can smoke; in so doing I ignore the label
> warning me that I will drop dead but only after I have poisoned the
> entire population. Is this wise? No. Will I be arrested for so doing?
> We'll see in SF.
> 
> Seriously, if there is only one entry in ENUM with a SIP AoR, and
> this is labelled with 'voice', then it may be tempting to ignore
> this label and try to use the AoR for other kinds of communication.
> In so doing, the end user should not be surpised if an attempted SIP
> session results in a rejection. If I dial a phone number labeled as
> voice and attempt to send a fax, again, I should be unsurpised if
> a fax doesn't pop out of the callee's ear.
> 
> The hint indicates a preference on the part of the Registrant. It
> SHOULD be considered by the end user when selecting between entries
> with different SIP AoRs, but it's possible for them to ignore this
> preference. ENUM can't block their actions subsequent on receiving
> the entries; if a DDDS implementation allows an end user to "break
> the tie" then this allows the end user to select any of the available
> entries.
> 

Well, just repeating myself here but two things:

1) Saying that the enumservice capability SHOULD be considered by the end
users means that their SIP application SHOULD NOT offer SDP that advertises
other services. That is, surprise surprise, a SIP behavior change that
requires SIP UAs to be aware of the ENUM process and modify their offers
accordingly, possibly to the detriment of SIP.

Actually, my second thing is the subject of the paragraph immediately below.

> The only question that remains is whether or not a DDDS implementation
> with knowledge of local capabilities will display an entry to the end
> user if its knowledge leads it to believe that it cannot support the
> labeled communication type.
> 

I think it's a little more cut-and-dry with that. The DDDS application will
display Rules associated with supported enumservices to the end user.
Applications presumably have to inform a DDDS resolver of which enumservices
they support (the 'capability' part), or users have to configure DDDS with
their understanding of this. I assume your vision is that if your device
only supports IM, it'll only look for IM-based enumservices. Again, if not,
then I don't see why 'E2U+sip' isn't good enough since the hint is
essentially discarded (and you have to inform DDDS to look for every
conceivable enumservice string that includes 'sip').

> Is that the whole issue here?
> 

Well, this is one of six or so issues in circulation in this thread, but
it's an important one, yes.

> 
> <snip -- there may be privacy issues - we agree>
> >  
> >
> >   Service negotiation goes well beyond caller prefs, which as you
surmise is
> >   not REQUIRED. See my previous note, especially the fourth bullet
point, on
> >   why primitives like 'voice' aren't really suitable for SIP capability
> >   negotiation. Incidentally, in parallel forking cases that are likely
when
> >   scanning multiple devices for a given capability, the offer/answer
cycles
> >   occur simultaneously, and don't result in any appreciable delay.
> >
> 
> In response to the "doesn't result in any appreciable delay", I have
> two comments:
> *  You have obviously not tried to use some of the early SIP
>     implementations on a 2G/2.5G 'phone :)
> 

I meant that SIP parallel forking does not result in any incremental delay
(over and above the delay of sending a single SIP call attempt).

> * An ENUM lookup and resolution is a pre-call activity, particularly if
>    the end user is involved in making a selection so "breaking the tie"
>    in the final round of DDDS processing. It's pretty quick, with just
>    one round trip of a short packet (in fact for some GPRS services, it
>    isn't even charged :).
> 
>    A SIP resolution that leads into a call may well be perceived as a
>    mid-call activity.
> 
>    Whether or not this is the case remains to be seen, until which time
>    I'm conservative in terms of what constitutes an appreciable delay.
> 

I don't have too much to say to any of these, other than that they are
implementation-specific points. A service provider could decide that DNS is
free and all SIP requests are charged $100 no matter what they intend. They
could also decide the reverse. Neither course is set in stone.

> Re. the points in your earliest posting, I will respond to 
> that shortly.
> 
> all the best,
>    Lawrence
> --