Draft:  draft-ietf-sipping-service-identification-01
Reviewer: Tolga Asveren [tasveren at sonusnet.com]
Review Date: 2 April 2008
Review Deadline: 11 April 2008
Status: WGLC 
Summary: This draft is on the right track but has open issues, described
in the review.

My comments from the initial review are addressed and most of my current
comments are about a follow-up discussion we had in SIPPING WG list
about an example, where a gaming application establishes a voice session
between players via SIP.

1) 1.Introduction
"Explicit service identifiers have many problems, however. They are
redundant with the signaling itself (which is the ultimate expression of
the service that is desired)"

Till that point, the document uses session/use case terminology. I would
expect the wording to be something like this: (which is the ultimate
expression of the session that is desired). With such a rewording, the
argument would become void, i.e. service-identifiers try to identify a
particular use case, not a session.

IMHO, signaling by itself does not always provide a unique
identification of the corresponding use case (a scenario of a SIP voice
session being used as part of a gaming application has been discussed in
the list. My understanding is that it is possible to think of cases,
where signaling won't provide sufficient information to select the right
application, e.g. if game move session is setup without SIP. 

Actually, "Introduction" section of the document captures the
distinction between session and use case pretty good.


2) 2. Services and Service Identification
"This leads naturally to the desire to perform service identification."
AFAIU from the steps listed afterwards, this should be more something
like "This leads naturally to the desire to use a Service-Identifier." 
The nuance is probably more about interpretation but the term "service
identification" seems to cover the problem in general, rather than a
particular mechanism.

3) 5.1 Services are a By-Product of Signaling
"A service is the by-product of the signaling and the context around it
(the user profile, time-of-day and so on)"
Assuming that URI per application approach is not utilized, this IMHO is
a "leap of faith". For *most* of the cases it could be true, but I think
it is possible to construct counter-examples, e.g. the gaming example
mentioned previously.

In any case, IMHO, it would make sense to analyze one example which
breaks this assumption (or demonstrate that such a difficult example
actually does not break this assumption, or enumerate the conditions,
which should be satisfied so that it doesn't break).

4) 5.2 Identical Signaling Produces Identical Services
Similar to 3).


5) 7 Recommendations
Using different URIs: I think, this is the safe and architecturally
correct way of dealing with this problem (especially about delivering
the session to the right application at the end device). IMHO, providing
an example utilizing this approach could be useful (maybe as part of the
same example showing how without separate URIs, signaling may not be
sufficient to determine the end user application)