Draft:  draft-ietf-sipping-service-identification-01.txt
Reviewer: Spencer Dawkins [spencer@mcsr-labs.org]
Review Date: 2/25/2008
Review Deadline: 4/11/2008
Status: RAI review 

Summary: Ready with comments

Comments:
---------
One is a request for a reference, and the other is a request for two
sentences, max.

If anyone thinks these comments matter, AUTH48 would be fine :-)

Thanks for dealing with the forest of stuff that you dealt with. I'm
deleting everything except my new comments below.

Spencer


>>   introduces numerous challenges.  One of these is that, when an
>>   endpoint generates a SIP INVITE for a session, or receives one, that
>>   session can potentially be within the context of any number of
>>   different use cases and endpoint types.  For example, a SIP INVITE
>>   with a single audio stream could represent a Push-To-Talk session
>>
>> Spencer (nit): got a reference for Push-to-Talk?
>
> Not really... there is probably some OMA reference but I don't think its 
> useful. In the modern era, google and wikipedia are better than any 
> reference I could give.

;-)

Perhaps our OMA liaison might provide something appropriate, while we're
preparing for our leap-to-hyperspace change in the philosophy of references
;-)

>>   Normally, this service would be backwards compatible with a regular
>>   audio-video endpoint, which would just reject the third media stream.
>>   However, because a large network has been deployed that is expecting
>>   to see the token, "multimedia conversation" and its associated audio+
>>   video service, it is nearly impossible for the new provider to roll
>>   out this new service.  If they did, it would fail completely, or
>>   partially fail, when their users call users in other provider
>>   domains.
>>
>> Spencer: I'm thinking this document is missing something I've heard a lot 
>> of discussion about - the idea that there are various "levels" of 
>> service, and we don't have any clue how to mix-and-match service 
>> identifiers. If you have an audio+video+avatar service and a push-to-talk 
>> service, how do you offer an audio+video+avatar+push-to-talk service? We 
>> know how to do this based on signaling (conceptually, when PTT signaling 
>> actually reflects what happens in PTT), but how do we tell the other end 
>> what to do using service identifiers?
>
> I think thats implied in the whole discussion about sip's ability to 
> negotiate fine grained capabilities for a session.

Yeah, I agree, but if people were good at figuring out what SIP's abilities
imply, you wouldn't be writing this draft, right?

This draft is very clear in explaining the negative impact on innovation if
service identifiers are used, but it may be worth pointing out that carriers 
can't even innovate by combining existing services that are only signaled 
using service identifiers - that's a different problem, and arguably even 
worse.