Subject: Re: [Sipping] draft-ietf-sipping-service-identification-01 WGLC review

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jul 2008 11:51:16 -0400

responses below:

Asveren, Tolga wrote:
> Draft:  draft-ietf-sipping-service-identification-01
> Reviewer: Tolga Asveren [[email-masked]]
> 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.

The document isn't saying that there is no such thing as 'service'; its 
saying that the 'service' is equivalent to the user-visible use case. 
 From section 2:

    Essentially, the service is the user-visible use case that is driving
    the behavior of the user-agents and servers in the SIP network.
> 
> 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. 

I had come to a different understanding from this thread. For that use 
case, the right way to set up the audio session is to use a different 
target URI, learned via the game rendezvous mechanism. When the audio is 
set up that way, the signaling is indeed different. If you didn't do 
that - if you used a regular audio call to the target user with a 
service identifier - you end up having the various problem the draft 
points out.

So i think the draft needs to add this use case you have suggested, and 
basically argue that, in such cases, you need to make the signaling look 
different by changing the target URI or else you are susceptible to the
various problems that are outlined.

Would this address your comment?

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

Right - so perhaps I just need to move that definition up into the intro.

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

This is a good point. Having put this draft down for a few months and 
re-reading it to do a revision, I think it is quite confused on this 
point. Indeed the draft says there is nothing wrong with determining an 
identifier and placing it into the message.

So the problem isn't service identification (which is a fine thing to do 
  - so long as its based on signaling), or even usage of an identifier 
based on that signaling. The peril that the draft is warning against is 
the practice of placing service identifiers in a reuqet that are 
required for request processing, and which are themselves not derivable 
from the signaling. Call this, "declarative service identifiers". I 
think the draft needs to be reworded a bit to make this clearer.

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

But the point is, that example causes problems - it easily leads to 
fraud and call failures. I think the lesson from that example is, you 
need ot MAKE your signaling different for these cases, using target URI, 
else you are susceptible to the problems described here.

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

Agreed.

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

Agreed.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www.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: "Asveren, Tolga" <[email-masked]>
Date: Fri, 11 Jul 2008 09:52:36 -0400

Jonathan,

I think all my comments would be answered with the additions you
mentioned in your reply.

Thanks,
Tolga

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, July 09, 2008 11:51 AM
> To: Asveren, Tolga
> Cc: sipping
> Subject: Re: draft-ietf-sipping-service-identification-01 WGLC review
> 
> responses below:
> 
> Asveren, Tolga wrote: