Subject: [Sipping] Comments to draft-rosenberg-sipping-service-identification-00.txt

From: Miguel Garcia <[email-masked]>
Date: Wed, 24 Jan 2007 15:11:09 +0200

Some comments to the Service Identification draft.

- The draft mandates the usage of the Require header including a service 
URN. I think this usage is too restrictive. Imagine I establish a 
session with you, using a given service, and I want to give you a hint 
of the service that I am using, but it is not strictly required that you 
use exactly the same service. For example: I am using my IM client to 
establish a voice session with you. It would be nice if you happen to 
have an IM service client that supports voice, since we can start with 
voice and add IM later. But it is not necessary: you could answer with 
your telephony client and we could still have voice among both. This 
seems to advocate a Supported header (hint) in some cases.

- I understand the motivation for overloading the Require header for 
transporting URNs, but I think it is an ugly solution, and the fact that 
the RFC says you can only insert standardized option tags is not enough 
to prevent people writing other non-standardize tags if they wish to 
violate the RFC. So, I was wondering why not creating a Service header 
or something like that. The header would have the same constrains about 
how to populate it. And I think it would also solve the previous issue: 
serve as a hint, rather than as a requirement.

- Populating the last Route entry with the Service URN is a nice 
feature. I was wondering if application servers will have to delete this 
last route when they execute the service. I didn't find much written on 
the draft. I think servers will not be able to delete this last route 
ever, because they cannot guarantee that other servers downstream will 
need the same entry to route to other application servers. Think of a 
service that requires originating and terminating support. The draft 
should in any case discuss this topic.

- A definitions section in the draft would help. At least, Service 
Instance URI and Service URI should go there.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Jan 2007 09:17:46 -0500

Comments inline.

> seems to advocate a Supported header (hint) in some cases.

This comment highlights the overlap between "service", "capability", and 
"preference".

What you describe is a caller that requires voice (generic voice - no 
special service involving voice), that has a capability to do IM, and 
that has a preference for contacting a UAS that supports IM as well as 
voice.

To deal with that, we already have callerprefs, and mmusic is working on 
SDP capability negotiation that also may bring something useful.

I don't see why the service identification mechanism has to solve this 
problem too.

> violate the RFC.

It doesn't prevent individuals, or developers of closed systems from 
doing so. But it does make it difficult for other SDOs from doing so, 
and developers of systems that interoperate with standards complying 
components will at least get some pressure.

This service mechanism has a high potential to create a real Tower of 
Babel if it isn't managed carefully.

> So, I was wondering why not creating a Service header 

I have similar concerns. The Route header is an interesting approach 
that I too like in some ways. But its far from clear how to partition 
responsibility in order to resolve issues such as the one you raise. 
Jonathan already included flexibility to reorder these. (And I already 
complained about the mechanism. I think those that add Route headers 
ought to get the say about what reordering is allowed, rather than 
having it determined by the type of URI.)

But reordering only helps if somebody has reason to know what order is 
appropriate. If the element adding the header didn't know the right 
order, then how can we expect some other element to know?

Your issue is a further extension. In addition to reordering, there is 
the issue of knowing when something has been done. With regular Route 
header values, containing SIP URIs, we generally assume that a server 
knows when it owns that URI, and then removes the Route header. I think 
we need to assume essentially the same model for URNs - the server knows 
when it supports one, and then removes it. If it thinks there is 
*another* server that also supports that URN, then it can add *another* 
Route for that. But of course that raises some horrible issues of 
looping that I don't immediately see how to resolve in the general case.

In the case of adding support on both the originating and terminating 
sides, this might be less of a problem. The UAC, or a proxy on the 
originating side acting for the UAC, can add a Route header with the 
URN, based on the presence of the Require header or something, and then 
this will be resolved on the originating side before the R-URI is 
translated to send the request to the terminating side. Then a proxy on 
the terminating side can add a Route header, again based on the Require 
header of something, which will then be resolved on the terminating side.

IMO it is fundamental that the UAC *not* make assumptions about how the 
service is implemented on the terminating side, as that prevents 
alternative implementations.

	Thanks,
	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 24 Jan 2007 17:12:28 +0200

Some inline thoughts.

Paul Kyzivat wrote:
>> - The draft mandates the usage of the Require header including a 
>> service URN. I think this usage is too restrictive. Imagine I 
>> establish a session with you, using a given service, and I want to 
>> give you a hint of the service that I am using, but it is not strictly 
>> required that you use exactly the same service. For example: I am 
>> using my IM client to establish a voice session with you. It would be 
>> nice if you happen to have an IM service client that supports voice, 
>> since we can start with voice and add IM later. But it is not 
>> necessary: you could answer with your telephony client and we could 
>> still have voice among both. This seems to advocate a Supported header 
>> (hint) in some cases.
> 

I would say ".... that has a preference for contacting the same service 
that the calling party is using". The reason is that future interactions 
may involve other capabilities that this service is able to offer.

> SDP capability negotiation that also may bring something useful.

I still don't see how I can signal my preference for a service to be used.

> I don't see why the service identification mechanism has to solve this 

Because for a basic communication (say voice), any UI or application 
will work, but for more advanced features, if both UAs have the same 
service through an implementation, then that is the desired effect. 
think the service ID fits perfectly in here.

>> transporting URNs, but I think it is an ugly solution, and the fact 
>> that the RFC says you can only insert standardized option tags is not 
>> enough to prevent people writing other non-standardize tags if they 
>> wish to violate the RFC.
> 

Agreed. My point is that you get the same effect by defining a new 
header and writing down the same constraints that Require has. IMHO this 
is not a justification for overloading the semantics of an existing header.

> Babel if it isn't managed carefully.

I fully agree. It makes me very nervous. And the only usage of the 
Require header makes me nervous exactly in this sense. I believe the 
service preference is enough in most cases, perhaps is the only one that 
should go into the draft.

> 
>> So, I was wondering why not creating a Service header or something 
>> like that. The header would have the same constrains about how to 
>> populate it. And I think it would also solve the previous issue: serve 
>> as a hint, rather than as a requirement.
>>
>> feature. I was wondering if application servers will have to delete 
>> this last route when they execute the service. I didn't find much 
>> written on the draft. I think servers will not be able to delete this 
>> last route ever, because they cannot guarantee that other servers 
>> downstream will need the same entry to route to other application 
>> servers. Think of a service that requires originating and terminating 
>> support. The draft should in any case discuss this topic.
> 
> when it supports one, and then removes it. 

This is the point where things fall apart. In general, a server will not 
have information of whether other servers downstream have to take an 
action based on the invoked service. In my opinion, there isn't harm in 
leaving a Route header there if the service URN was there, so that 
routing can still continue downstream and other servers might get 
involved, if required.

> If it thinks there is 
> Route for that. 

Well, on the wire there is no difference between preserving the service 
URN and first removing it and then add it again.

> But of course that raises some horrible issues of 

That is right. There should be me some mechanism to avoid loops. I am 
not sure if the general SIP mechanism for loop avoidance is enough.

> header of something, which will then be resolved on the terminating side.

This is weird. So we have a proxy inspecting headers to determine that a 
SIP request should be routed to the Service application server.... I 
thought that was the sole purpose of adding the Service URN to the Route 
header.

> alternative implementations.

Agreed.

>     Paul

BR,

        Miguel

---

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Wed, 24 Jan 2007 17:27:55 +0200

Hino,

I have read the draft and I think is good that it clearly acknowledges
the need for service identification.

However, the draft really does not seem to have a clear argument to
use service URN/Require header/Route header mechanisms vs media feature
tag to identify services, or at least I am not able to see the
advantages.

see also my comments in line

/sal

> I don't see why the service identification mechanism has to solve this 

here I agree with Miguel, the usage of Require header is too
restrictive. Actually the tag, whatever, a feature tag like in 3gpp
solution or a URN like in the Rosemberg proposal, should be only
informative.

Of course for IM and Voice scenario described Paul is right, 
we can handle this scenario with callerprefs, 
but what about the scenario where I want start a PoC session with you,
but if you don t have a PoC client I want establish a normal audio
session. If I use the Require header solution this is not possible at
all.

I really do belive that the Require header proposal destroy all the
service URN potentiality:
"The URN consists of a hierarchical service identifier, ...
For any given service URN, service-identifiers can be removed
right-to-left and resulting URN is still valid, referring a more generic
service" (draft-ietf-ecrit-service-urn-05 in Section 3)

> Babel if it isn't managed carefully.

Paul I see what you are afraid about the risk in the service mechanism,
but in this way IETF should start to standardize and take care also of
the services. I don´t know if this is a good idea.

> alternative implementations.

the mechanism to trigger an application server in both originating and
terminating side, is not clear in the draft.
And the solution proposed above, to clarify the usage in the terminating
side, seems to be a little bit too complicate.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Jan 2007 11:24:35 -0500

More comments...

Miguel Garcia wrote:
>>> give you a hint of the service that I am using, but it is not 
>>> strictly required that you use exactly the same service. For example: 
>>> I am using my IM client to establish a voice session with you. It 
>>> would be nice if you happen to have an IM service client that 
>>> supports voice, since we can start with voice and add IM later. But 
>>> it is not necessary: you could answer with your telephony client and 
>>> we could still have voice among both. This seems to advocate a 
>>> Supported header (hint) in some cases.
>>
>> This comment highlights the overlap between "service", "capability", 
>> and "preference".
>>

This emphasizes a key philosophical difference I think - one that goes 
all the way back to the early discussions around rpids and the meaning 
of "service" in presence. One approach is that a service is just a 
collection of capabilities. (Your "IM Service Client" is just a 
combination of an audio capability and an IM capability.) The other 
approach is that a service has an arbitrary name, which implies some 
combination of capabilities and ways to use those capabilities, but 
doesn't explicitly state what the capabilities are. It is assumed that 
if you support the service then you know what it implies.

Jonathan has attempted to thread the needle once again regarding that 
difference. But it doesn't seem to be succeeding. He was trying to draw 
the distinction between what the capabilities are, and how they are 
used. (So that audio and IM used to support a chess game is different 
from audio and IM used conversationally.)

In the example you give, it doesn't seem to me that any special service 
is needed (or depending on your viewpoint, some generic personal 
communications service may be appropriate - whatever is normally used 
for regular calling.)

>> To deal with that, we already have callerprefs, and mmusic is working 
>> on SDP capability negotiation that also may bring something useful.
> 

Lets go to Jonathan's example of the Chess service. If you were calling 
from your chess program, I think you would have more than a "preference" 
for a chess service at the other end. Conversely, if you are not calling 
from your chess program, then you don't want a chess service at the 
other end.

For services to be anything different from capabilities and preferences, 
  I find it hard to see how they can be optional.

> think the service ID fits perfectly in here.

Why isn't IM, and Video, also considered "basic communication"?

IMO basic communication is that we can establish a sip session and then 
we use sip to negotiate the media that we will use in that session. We 
both trust the other side to be able to utilize the media in some 
appropriate way. That may be a human being communicating in an ad-hoc 
manner.

It may be an IVR that has a particular kind of communication it carries 
out when called. As such, an IVR could conceivably be called a 
"service". For instance an airline reservation service or a pharmacy 
prescription ordering service. But hopefully they aren't services in the 
sense discussed by this draft - the caller doesn't have to specify the 
service in the request in order for it to be handled by the proper IVR.

> is not a justification for overloading the semantics of an existing header.

I don't have a strong feeling on this point. I think jonathan's intent 
in going this way was a belief that this isn't really overloading - that 
the purpose really is the same - that chess is an option in the same way 
that 100rel is an option.

>>> populate it. And I think it would also solve the previous issue: 
>> knows when it owns that URI, and then removes the Route header. I 
>> think we need to assume essentially the same model for URNs - the 
>> server knows when it supports one, and then removes it. 
> 
> action based on the invoked service.

If it doesn't, then it shouldn't be inserting a Route header. Only an 
element that does have the information should add the header.

> In my opinion, there isn't harm in 
>> If it thinks there is *another* server that also supports that URN, 
>> then it can add *another* Route for that. 
> 

There is no observable difference from the outside of the black box. But 
there is a conceptual difference. When you receive the request, if the 
Route header matches you, then you should remove it. Then, if you think 
you know of another hop that ought to be involved then you can add a 
Route header for that.

I think this might be clearer if we discuss how a Route header with a 
URN is to be handled. I expect that some server should take 
responsibility for resolving it. That would involve translating the URN 
to a URI using some mechanism. Then a Route header containing the 
translation should replace that containing the URN, and routing of the 
request can continue. The resolution could be by a server different from 
the one identified by the translation, or it could be that the server 
translating it says "I am responsible for that". In the latter case, 
conceptually it would translate. Then once there is a Route header 
identifying itself it would remove that. (In practice of course it can 
just remove the Route header containing the URN, but the model gives the 
rationale for removing.)

>> But of course that raises some horrible issues of looping that I don't 
>> immediately see how to resolve in the general case.
> 

I think they should be enough to detect the loop. But you really want to 
prevent the loop.

Consider an IMS environment. Perhaps the S-CSCF is responsible for 
resolving a Route header containing a URN, replacing with one 
identifying what is most likely an AS, and then routing to it. The AS 
would then remove itself from the route. As long as nobody adds another 
Route for the same URN in things are then ok. But if that AS, or 
another, adds back a Route for that URN then a loop is created with no 
obviously easy way to resolve.

Alternately, the S-CSCF might not replace the URN when resolving it, but 
rather leave it in place and simply route the request to the resolved 
address. And then that server could potentially just leave the URN in 
the route. In that case again there is a troublesome loop.

>> URN, based on the presence of the Require header or something, and 
>> then this will be resolved on the originating side before the R-URI is 
>> translated to send the request to the terminating side. Then a proxy 
>> on the terminating side can add a Route header, again based on the 
>> Require header of something, which will then be resolved on the 
>> terminating side.
> 

As I understand it, the point is for whatever component knows that the 
server is needed should add the Route. If the UAC knows then it should 
add it. If the originating proxy knows, then *it* should add it. This 
depends on your view of how responsibility for features is distributed 
among the pieces of the system.

>> IMO it is fundamental that the UAC *not* make assumptions about how 
>> the service is implemented on the terminating side, as that prevents

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Jan 2007 12:38:34 -0500

> tag to identify services, or at least I am not able to see the

Well, as you can see from my other comments, I have for *years* not been 
able to distinguish the difference between services and capabilities. 
IMO it indeed should be possible to use capabilities and preferences as 
an alternative to services.

BUT, the examples of services that I often see used don't line up with 
capabilities very well, at least the way they are being done.

So, I think it is fine to use capabilities and preferences for those 
cases where they fit without abusing the callerprefs mechanism. And if 
there are then other things that can't be done that way, then some new 
mechanism may still be needed.

I think one part that callerprefs doesn't support well, if at all, is 
the inclusion of intermediate servers into the call path. Certainly 
there is nothing in RFCs 3840 and 3841 that provides a way to do so, 
unless you use it to select a B2BUA to terminate your call, after which 
the B2BUA would need to orignate some other call. But doing that would 
imply that the B2BUA was one of the candidates in the location server 
for the AOR being called. And even then that would only cover the 
terminating side - it wouldn't help in getting an intermediate server 
into the originating side of a call.

Its my impression that one IMS proposal for this (from Ericsson I think) 
is indeed to use a media feature tag in an accept-contact header. Then 
to involve in intermediate server, an S-CSCF (orig or term) would match 
the existence of the feature tag in an accept-contact header and use 
that as an indication that an intermediate server was required. What I 
haven't seen is any explanation of how that would work given that 
callerprefs permits complex expressions that end up excluding some 
candidates and prioritizing others. For instance one might specify in an 
accept-contact that you want (AUDIO and VIDEO and *not* POC), or that 
AUDIO should be tried first, and if that is unsuccessful then try POC.

If the use of media feature tags for identifying services then restricts 
the ways in which callerprefs can be used, then it is an abuse and 
should not be pursued.

> solution or a URN like in the Rosemberg proposal, should be only

See my response to Miguel

> session. If I use the Require header solution this is not possible at

If you want a call that prefers POC but will take normal audio as a 
fallback, then the case fits callerprefs pretty well - if POC is 
implemented entirely in the UAC and UAS.

But if POC requires a server in the path, and normal audio doesn't, then 
callerprefs aren't a very good fit for this, and in fact it isn't clear 
to me how you would do this. (I think the proper way is probably to 
establish the call e2e and then have the UAC and UAS invoke a helper 
server if needed for POC.

> the services. I don´t know if this is a good idea.

To paraphrase, I think services should be "rare and safe."

I fear that only the ietf is concerned about this risk, and think that 
unless we do something to prevent it there is *substantial* risk that a 
large percentage of calls will be made in a way that is only 
interoperable within a closed club of players.

I do think the callerprefs mechanism, used as intended, has fewer 
potential problems, as long as new capabilities are truly distinct and 
orthogonal to other capabilities, rather than being opaque named 
collections of capabilities.

> side, seems to be a little bit too complicate.

I am inclined to agree. We suffer because the kinds of things an 
intermediate server would do if involved in a call in order to 
facilitate a "service" is not even within the vocabulary of the ietf. It 
feels to me that we are dancing around the elephant in the room without 
acknowledging its presence.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Jan 2007 20:44:25 -0500

Splitting this thread up a bit, since we are discussing two separate points.

inline.

Paul Kyzivat wrote:

>>>> strictly required that you use exactly the same service. For 
>>>> example: I am using my IM client to establish a voice session with 
>>>> you. It would be nice if you happen to have an IM service client 
>>>> that supports voice, since we can start with voice and add IM later. 
>>>> But it is not necessary: you could answer with your telephony client 
>>>> and we could still have voice among both. This seems to advocate a 

I think this use case you are describing is NOT the problem that the 
option tag is trying to solve. In this case, there is not some 
additional context on how the signaling or media is interpreted which 
would prevent normal SIP mechanisms from working. You would not need a 
Require in the above case. The 'service' is basic SIP communications, as 
Paul has indicated.

>>> that has a preference for contacting a UAS that supports IM as well 
>>> as voice.
>>
>>
>> I would say ".... that has a preference for contacting the same 
>> service that the calling party is using". The reason is that future 
>> interactions may involve other capabilities that this service is able 
>> to offer.
> 
> 

Exactly. In my mind, the service ID is used when there is some context 
on the side of the originator that governs the interpretation of the 
signaling or media that MUST be shared by the remote side to sensibily 
make use of the session, which is not otherwise signaled by SIP since 
its not a PROTOCOL issue.

I give this example of chess, where a session set up from the chess app 
LOOKS IDENTICAL to a SIP request initiated by a regular telephony app. 
Its only when there is nothing in the protocol to differentiate, that it 
changes from a capability to a required service.

In essence, the option tag in Require has the effect of partitioning a 
SIP network into non-overlapping services, all of which share the 
infrastructure but otherwise can exist for various purposes. Like it or 
not (and I don't) it is my understanding that there is a strong desire 
from the community to have a technique to do exactly this; to allow 
their IMS to support several services which use IMS but which are 
otherwise quite separate and go with their own apps on the phone. PoC in 
particular makes use of some pretty unusual call flows that work ONLY 
under the assumption of mutual understanding that this is PoC; this 
would be a contender for a service URI because of that assumption.

Indeed, it was my understanding here that this was exactly what is 
desired for PoC. I make a call from my PoC client to a number. If the 
terminating user doesn't have POC, they better not accept that call or 
bad things are going to happen. That is Require in every sense of the 
mechanism.

> from your chess program, then you don't want a chess service at the 

Right. I think if this is something in the category of a preference that 
can be signaled, then it is normally within the context of a single 
service and that preference would not be signaled using Require.

There is a use case where my phone has this voice-chess app and a normal 
telephony communications app. I 'call' you, indicating we can EITHER do 
voice-chess OR telephony. You pick which one, and both of our phones 
launch teh appropriate app based on this.

I personally think this is an unlikely use case; it could be supported 
by placing the set of services in Supported as you suggest, and the 
response including Require. Lack of a Require in the response means that 
no special service was selected; its just normal multimedia 
communications as SIP normally does.

A far better way to select amongst these services is presence. IMHo that 
is far more elegant and user firendly. I would select a user in my 
address book, and it would show (using presence), the services I can 
get. I would then choose and send an INVITE. I think the notion of 
callee choosing the service is misguided since it is the caller that has 
asked for communications, they are the ones who know WHY they have asked 
for it, and thus what the right service is for that communications. That 
is why presence is so powerful - it enables choice. Please look at the 
presence data model spec which tries to explain this more.

>>> I don't see why the service identification mechanism has to solve 
>>> this problem too.
>>
>>

Yes, exactly.

> service in the request in order for it to be handled by the proper IVR.

No - an IVR isn't a different service. Here is my take on it. 'basic 
communication' as a service involves the establishment of multimedia 
communications for the purposes of human interaction; the origination 
and consumption of media is governed solely by what the calling or 
called user wishes to say as part of that communications. IVRs have a 
particular 'thing' they want to "say" - the IVR tree. The voice-chess is 
different because the media is not consumed by the called user based on 
what they'd want to say; its consumed by an auotomata that may or may 
not be there.

The distinction is fuzzy, but everything about this problem is splitting 
hairs.

>>>> that the RFC says you can only insert standardized option tags is 
>>>> not enough to prevent people writing other non-standardize tags if 
>>>> they wish to violate the RFC.
>>>
>>>
>> header and writing down the same constraints that Require has. IMHO 
>> this is not a justification for overloading the semantics of an 
>> existing header.
> 
> 

Exactly. It is PRECISELY the semantics of require. What we want is a way 
to say, "hey, if you get this request, and you don't understand service 
foo, you rae NOT going to do the right thing in processing this, so you 
BETTER support it". Whats new is that the Require is pointing to 
application-layer context, not SIP protocol mechanisms.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Jan 2007 08:58:17 -0500

I pretty much agree with everything Jonathan says below. I'm snipping 
one point for further comment.

	Paul

Jonathan Rosenberg wrote:

>> IMO basic communication is that we can establish a sip session and 
>> then we use sip to negotiate the media that we will use in that 
>> session. We both trust the other side to be able to utilize the media 
>> in some appropriate way. That may be a human being communicating in an 
>> ad-hoc manner.
> 
> Yes, exactly.
> 
>> It may be an IVR that has a particular kind of communication it 
>> carries out when called. As such, an IVR could conceivably be called a 
>> prescription ordering service. But hopefully they aren't services in 
>> the sense discussed by this draft - the caller doesn't have to specify 
>> the service in the request in order for it to be handled by the proper 
>> IVR.
> 

Yes, it is fuzzy. Thinking about it further, I guess I agree with 
Jonathan on this point too. The key distinction here is that while the 
UAS may have a service-like context, the UAC doesn't have to be aware of 
it or have any special support for it. As a result, the context needed 
at the UAS should be determined by some other means, not a service 
identifier supplied by the caller. For instance, it is ofter determined 
by the request URI.

---

From: [email-masked]
Date: Mon, 29 Jan 2007 16:24:18 -0500

I'm a little mystified at what problem this architecture is supposed
to solve.  I know that it is to form a sort of "sub-addressing" within
the target's AOR, but I don't see the particular use of that, since a
user can easily mint a new AOR for every application he wishes to
maintain.  (By hypothesis, these applications are intended to be
long-lived and publically available (for some public, perhaps small).)
If someone wants to connect to my chess application, he is presumably
a chess fanatic that I know, and I can give him the appropriate AOR by
various means.

Where the idea becomes truly useful is if a service designation can be
thought of as being a potential modifier for *every* AOR in a large
set.  This is implied in the requirements:

   REQ 5: It must be possible for a user to initiate a session without
      knowledge of any information about the recipient except for their
      AOR.

   REQ 6: The mechanism must allow a presence server to determine the
      services on the phone, without requiring [advance] knowledge of
      those services.

Sort of like being able to tag a company's phone number with "fax" and
automagically getting routed to their fax number.

But I see that the number of those is going to be small.  Even now,
there are only 4 contact info items for an organization:  main phone
#, fax phone #, web URL, and postal address.

Where this becomes interesting is if there are many, large,
overlapping communities within which there are a significant number of
applications that a majority of members implement.  But I can't
imagine how that would come about.

Dale

---

From: <[email-masked]>
Date: Tue, 30 Jan 2007 12:30:45 +0530

Comments inline.

Regards,
Ravi.

--
 
Ravishankar. G. Shiroor
Wipro Technologies, Bangalore.
 
[email-masked]
--

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, January 30, 2007 2:54 AM
> To: [email-masked]
> Subject: [Sipping] draft-rosenberg-sipping-service-identification-00
> 
> I'm a little mystified at what problem this architecture is 
> supposed to solve.  I know that it is to form a sort of 
> "sub-addressing" within the target's AOR, but I don't see the 
> particular use of that, since a user can easily mint a new 
> AOR for every application he wishes to maintain.  (By 
> hypothesis, these applications are intended to be long-lived 
> and publically available (for some public, perhaps small).) 
> If someone wants to connect to my chess application, he is 
> presumably a chess fanatic that I know, and I can give him 
> the appropriate AOR by various means.
> 
> Where the idea becomes truly useful is if a service 
> designation can be thought of as being a potential modifier 
> for *every* AOR in a large set.  This is implied in the requirements:
> 
> Sort of like being able to tag a company's phone number with 
> "fax" and automagically getting routed to their fax number.
> 
> But I see that the number of those is going to be small.  
> Even now, there are only 4 contact info items for an 
> organization:  main phone #, fax phone #, web URL, and postal address.
> 
> overlapping communities within which there are a significant 
> number of applications that a majority of members implement.  
> But I can't imagine how that would come about.

NGN standards like IMS promise roll-out of services at a higher speed
than it is possible today.
Given that, it would be possible to have large number of applications
and services used by large number of users.

> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>