[Sipping] response to APPS-REVIEW of draft-ietf-sipping-service-identification-00

[Jonathan Rosenberg <[e-mail]>]

Claudio,

You posted a review of this document back in November:
http://www.ietf.org/mail-archive/web/apps-review/current/msg00112.html

I am very delinquent in this update, and apologize for the long delay in 
responding. Thanks for the comments. Responses below:

> General Comments:
> 
> 
> The idea and the problem being addressed is described quite clearly
> in the "Introduction" section. However the Abstract itself seems to
> stress to much the "legal/fraud" bullet point, while the focus of the
> document indeed is elsewhere and more general. I would add a more
> coherent abstract instead of the current one.

The abstract only list fraud as one of several concerns, so I don't see 
how the abstract was emphasizing it. Anyway I tried to reword to align 
it more closely with the flow of the document. So now it reads:

             <t>This document considers the problem of service
	    identification in the Session Initiation Protocol
	    (SIP). Service identification is the process of
	    determining the user-level use case that is driving the
	    signaling being utilized by the user agent. This document
	    discusses the uses of service identification, and outlines
	    several architectural principles behind the process. It
	    identifies several perils associated with service
	    identification, including fraud, interoperability failures
	    and stifling of innovation.
	    </t>


> 
> The term "user agent" is used in the document more as identifying the
> "hardware device", specifically when it states that multiple
> application can run within the same user agent, etc.

Actually it is referring to a SIP user agent, defined in RFC 3261. There 
is a common practice for multiple applications to make use of a common 
SIP stack. I've clarified this in that section:

In some of the examples above, there were multiple software
applications executing on the host. One common way of achieving this
is to utilize a common SIP user agent implementation that
listens for requests on a single port. When an incoming


  This is not
> coherent with the normal definition of user agent, which corresponds
> to a specific application running inside a hardware device (the
> super-classical e-mail User Agent programme, running within a PC,
> mobile device, whatever...). It might lead to confusion.
> 
> As a final general comment, the document itself is a Reccommendation
> more than a BCP in itself... are we sure this is the correct track to
> put it forward?

Informational is probably appropriate here. I changed.

> 
> Conclusion: IMHO ths document is useful, and should be pushed
> forward, even if it might sound "strange" a document whose aim is to
> prevent a potentially BAD practice... I really to not know if it
> whould be better to have this as somthing else than BCP... I would
> call it something in a category like "things you should not do".
> 
> ;-)
> 
> 
> from now on, se inline...
> 
> 
> Best regards, and sorry for being a bit late in the revision!
> 
> 
> Claudio
> 
> 
> -------------
> 
> 
> Detailed inline review:
> 
> 
> see below, notes labelled by ***, some portions of the draft omitted:
> 
> 
> 
> SIPPING                                                     J.
> Rosenberg Internet-Draft
> Cisco Intended status: Best Current
> August 1, 2007 Practice Expires: February 2, 2008
> 
> 
> 
> Identification of Communications Services in the Session Initiation 
> Protocol (SIP) draft-ietf-sipping-service-identification-00
> 
> 
> 
> <.. omitted ..>
> 
> 
> Abstract
> 
> 
> This document considers the problem of service identification in the 
> Session Initiation Protocol (SIP).  Service identification is the 
> process of determining the user-level use case that is driving the 
> signaling being utilized by the user agent.  While seemingly simple, 
> this process is quite complex, and when not addressed properly, can 
> lead to fraud, interoperability problems, and stifling of innovation.
> 
> 
> 
> *** see general comment above.

see my new abstract above.

> 
> 
> Rosenberg               Expires February 2, 2008                [Page
> 1]
> 
> 
> Internet-Draft                 Service ID                    August
> 2007
> 
> 
> 
> This document discusses these problems and makes recommendations on 
> how to address them.
> 
> 
> <.. omitted ..>
> 
> 
> Rosenberg               Expires February 2, 2008                [Page
> 2]
> 
> 
> Internet-Draft                 Service ID                    August
> 2007
> 
> 
> 
> 1.  Introduction
> 
> 
> The Session Initiation Protocol (SIP) [2] defines mechanisms for 
> initiating and managing communications sessions between agents.  SIP 
> allows for a broad array of session types between agents.  It can 
> manage audio sessions, ranging from low bitrate voice-only up to 
> multi-channel hi fidelity music.  It can manage video sessions, 
> ranging from small, "talking-head" style video chat, up to high 
> definition multipoint video conferencing, to low bandwidth user- 
> generated content, up to high definition movie and TV content.  SIP 
> endpoints can be anything - adaptors that convert an old analog 
> telephone to Voice over IP (VoIP), dedicated hardphones, fancy 
> hardphones with rich displays and user entry capabilities, softphones
>  on a PC, buddylist and presence applications on a PC, dedicated 
> videoconferencing peripherals, and speakerphones.
> 
> 
> This breadth of applicability is SIPs greatest asset, but it also 
> 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 
> between mobile devices, a VoIP session between softphones, or audio- 
> based access to stored content on a server.
> 
> 
> These differing use cases have driven implementors and system 
> designers to seek techniques for service identification.  Service 
> identification is the process of determining and/or signaling the 
> specific use case that is driving the signaling being generated by a 
> user agent.  At first glance, this seems harmless and easy enough. It
> is tempting to define a new header, "Service-ID", for example, and 
> have a user agent populate it with any number of well-known tokens 
> which define what the service is.  This information could then be 
> consumed for any number of purposes.
> 
> 
> *** it is unclear at this point if the idea of the new header here is
> being anyhow suggested, depracted, or an alternate better solution
> should be stanrdised. I guess it should make such a statement,
> already at this point, to clarify.


Its saying that doing something like that is a bad idea. I make that 
statement clearly here now:

which define what the service is. This information could then be
consumed for any number of purposes. This approach has many problems,
however. Inclusion of an explicit service identifier in the request
can very easily lead to
fraud, systemic interoperability failures, and a complete stifling of
the innovation that SIP was meant to achieve. The purpose of this
document is to describe service identification in more detail and
describe how these problems arise.
</t>



> 
> However, as this document will demonstrate, service identification is
>  a very complex and difficult process, and can very easily lead to 
> fraud, systemic interoperability failures, and a complete stifling of
>  the innovation that SIP was meant to achieve.
> 
> 
> Section 3 begins by defining a service and the service identification
>  problem.  Section 4 gives some concrete examples of services and why
>  they can be challenging to identify.  Section 5 explores the ways in
>  which a service identification can be utilized within a network. 
> Next, Section 6 discusses the key architectural principles of service
>  identification, and how explicit service identifiers can lead to 
> fraud, interoperability failures, and stifling of service innovation.
> 
> 
> 
> 
> 
> 
> Rosenberg               Expires February 2, 2008                [Page
> 3]
> 
> 
> Internet-Draft                 Service ID                    August
> 2007
> 
> 
> 
> 2.  Terminology
> 
> 
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
> document are to be interpreted as described in RFC 2119 [1].
> 
> 
> 
> 3.  Services and Service Identification
> 
> 
> The problem of identifying services within SIP is not a new one.  The
>  problem has been considered extensively in the context of presence. 
> In particular, the presence data model for SIP [3] defines the 
> concept of a service as one of the core notions that presence 
> describes.  Services are described in Section 3.3 of RFC 4479, which 
> has this to say on the topic:
> 
> 
> *** as a general procedural suggestion, I would avoid quoting full
> sections of existing other documents, as they may be updated,
> obsoleted, etc, creating corss reference problems more complex than
> needed if full quoting is used. Replacing the "included" session with
> a reference and just a few significant senteces makes it better. And,
> people redint this BCP shall have no problems in reading the full
> original section, or updates, themselves.

OK.


> 
> 3.3.  Service
> 
> 
> Each presentity has access to a number of services.  Each of these 
> represents a point of reachability for communications that can be 
> used to interact with the user.  Examples of services are telephony 
> (that is, traditional circuit-based telephone service), push-to-talk,
>  instant messaging, Short Message Service (SMS), and Multimedia 
> Message Service (MMS).
> 
> 
> *** for example, the definition of "presentity" is missing here,
> forcing the cautious readed to grab and read the original
> specification anyhow :-)

Inline text was removed.

> 
> It is difficult to give a precise definition for service.  One 
> reasonable approach is to model each software or hardware agent in 
> the system as a service.  If a user starts a softphone application on
> 
> 
> 
> <.. omitted ..>
> 
> 
> Essentially, the service is the user-visible use case that is driving
>  the behavior of the user-agents and servers in the SIP network. 
> Being user-visible means that there is a difference in user 
> experience between two services that are different.  That user 
> experience can be part of the call, or outside of the call.  Within a
>  call, the user experience can be based on different media types (an 
> audio call vs. a video chat), different content within a particular 
> media type (stored content, such as a movie or TV session), different
>  devices (a wireless device for "telephony" vs. a PC application for 
> "voice-chat"), different user interfaces (a buddy list view of voice 
> on a PC application vs. a software emulation of a hard phone), 
> different communities that can be accessed (voice chat with other 
> users that have the same voice chat client, vs. voice communications 
> with any endpoint on the PSTN), or different applications that are 
> invoked by the user (manually selecting a push-to-talk application 
> from a wireless phone vs. a telephony application).  Outside of a 
> call, the difference in user experience can be a billing one (cheaper
>  for one service than other), a notification feature for one and not 
> another (for example, an IM that gets sent whenever a user makes a
> 
> 
> 
> 
> Rosenberg               Expires February 2, 2008                [Page
> 5]
> 
> 
> Internet-Draft                 Service ID                    August
> 2007
> 
> 
> 
> call), and so on.
> 
> 
> In some cases, there is very little difference in the underlying 
> technology that will support two different services, and in other 
> cases, there are big differences.  However, for purposes of this 
> discussion, the key definition is that two services are distinct when
>  there is a perceived difference by the user in the two services.
> 
> 
> *** the whole above descriptive section is mabe even too long. The
> concept is made clear in the last above sentence "However... in the
> two services", hence I suggest shrinking the previous descripive
> text.

One thing that was clear in the many discussions leading up to this 
draft, is that lack of examples made any conversation on the topic hard 
to understand. Everyone had a different idea in mind of what things like 
service, user experience, and so on, meant. So I think it is important 
to retain this text.

> 
> This leads naturally to the desire to perform service identification.
>  Service identification is defined as the process of (1)
> determination of the underlying service which is driving a particular
> signaling exchange, (2) associating that service with some kind of
> moniker, and (3) attaching that moniker to a signaling message
> (typically a SIP INVITE), and then utilizing it for various purposes
> within the network.  Service identification can be done in the
> endpoints, in which case the UA would insert the moniker directly
> into the signaling message based on its awareness of the service.
> Or, it can be done within a proxy in the network, based on inspection
> of the SIP message, or based on hints placed into the message by the
> user.
> 
> 
> 
> 4.  Example Services
> 
> 
> It is very useful to consider several example services, especially 
> ones that appear difficult to differentiate from each other.
> 
> 
> 4.1.  IPTV vs. Multimedia
> 
> 
> IP Television (IPTV) is the usage of IP networks to access 
> traditional television content, such as movies and shows.  SIP can be
>  utilized to establish a session to a media server in a network,
> which then serves up multimedia content and streams it as an audio
> and video stream towards the client.  Whether SIP is ideal for IPTV
> is, in itself, a good question.  However, such a discussion is
> outside the scope of this document.
> 
> 
> Consider multimedia conferencing.  The user accesses a voice and 
> video conference at a conference server.  The user might join in 
> listen-only mode, in which case the user receives audio and video 
> streams, but does not send.
> 
> 
> These two services - IPTV and multimedia conferencing, clearly appear
>  as different services.  They have different user experiences and 
> applications.  A user is unlikely to ever be confused about whether a
>  session is IPTV or multimedia conferencing.  Indeed, they are likely
>  to have different software applications or endpoints for the two 
> services.
> 
> 
> *** make it MORE clear that the multimedia conference you're talking
> about is the ONE WAY unidirectional "listening only" version of it.
> It might be more appropriate to call it "multimedia conference
> listening", or something similar for the purpouse of this example.

OK. I called it 'listen-only multimedia conferencing'.


> 
> 
> 
> Rosenberg               Expires February 2, 2008                [Page
> 6]
> 
> 
> Internet-Draft                 Service ID                    August
> 2007
> 
> 
> 
> However, these two services look remarkably alike based on the 
> signaling.  Both utilize audio and video.  Both could utilize the 
> same codecs.  Both are unidirectional streams (from a server in the 
> network to the client).  Thus, it would appear on the surface that 
> there is no way to differentiate them, based on inspection of the 
> signaling alone.
> 
> 
> 4.2.  Gaming vs. Voice Chat
> 
> 
> Consider an interactive game, played between two users from their 
> mobile devices.  The game involves the users sending each other game 
> moves, using a messaging channel, in addition to voice.  In another 
> service, users have a voice and IM chat conversation using a buddy 
> list application on their PC.
> 
> 
> In both services, there are two media streams - audio and messaging. 
> The audio uses the same codecs.  Both use the Message Session Relay 
> Protocol (MSRP) [5].  In both cases, the caller would send an INVITE 
> to the AOR of the target user.  However, these represent fairly 
> different services, in terms of user experience.
> 
> 
> *** expand AOR acronym here, as it is the first occurence of it.

Done. Its Address of Record.

> 
> 
> <.. omitted ..>
> 
> 
> 5.  Using Service Identification
> 
> 
> It is important to understand what the service identity would be 
> utilized for, if known.  The discussions in Section 4 give some hints
> 
> 
> 
> 
> 
> Rosenberg               Expires February 2, 2008                [Page
> 7]
> 
> 
> Internet-Draft                 Service ID                    August
> 2007
> 
> 
> 
> to the possible usages.  Here, we explicitly discuss them.
> 
> 
> 5.1.  Application Invocation in the User Agent
> 
> 
> In some of the examples above, there were multiple software 
> applications running within a single user agent.  When an incoming
> 
> 
> *** see "User Agent" term use note I made inside the General Comments
> above.

Hopefully my suggested text makes this clear now.

> 
> *** is this sections exp;icitly suggesting the creation of the UI
> given in the figure below? It is not crstal clear... or it is just
> using the idea as a basis for discussiong its consequences if used?

Its saying that, in cases where the software is structured this way - 
with a common sip listener - you have this problem. Its the client-side 
equivalent of having a web server listen for requests for multiple 
different domains. You need something in the request itself (in the case 
of http, its the r-uri) to dispatch to the right application. However in 
SIP the request-uri will be the same for all requests, since it is 
entered by the user - i.e., I'd type "[e-mail]" in all cases. So 
something else - a service identity - is needed to dispatch.



> 
> I would clarify this in the begining of it.
> 
> 
> INVITE or MESSAGE arrives, it must be delivered to the appropriate 
> application software.  When each service is bound to a distinct 
> software application, it would seem that the service identity is 
> needed to dispatch the message to the appropriate piece of software. 
> This is shown in Figure 2.
> 
> 
> +---------------------------------+ |
> | | +-------------+ +-------------+ | | |     UI      | |     UI
> | | | +-------------+ +-------------+ | | +-------------+
> +-------------+ | | |             | |             | | | |  Service 1
> | |  Service 2  | | | |             | |             | | |
> +-------------+ +-------------+ | | +-----------------------------+ |
>  | |                             | | | |             SIP
> | | | |            Layer            | | | |
> | | | +-----------------------------+ | |
> | +---------------------------------+
> 
> 
> Physical Device
> 
> 
> Figure 2
> 
> 
> <.. omitted ..>
> 
> 
> 6.  Key Principles of Service Identification
> 
> 
> In this section, we describe some of the key principles of performing
>  service identification.
> 
> 
> 6.1.  Services are a By-Product of Signaling
> 
> 
> *** this section clearly states principles and reasons behind them.
> This is where the reference in the introduction should point for
> clarification of the suggestion that service-id is suggested or not.

Reference added. I reorganized this too so that there was a top-level 
section with principles and a separate top-level section with problems.

> 
> This is ultimately an expression of the principle of DWIM vs. DWIS 
> (Do-What-I-Mean vs. Do-What-I-Say).  Explicit signaling is DWIS - the
>  user is asking for a service by invoking the signaling that results 
> in the desired effect.  A service identifier is DWIM - an unspecific 
> request for something that is ill-defined and non-interoperable.
> 
> 
> *** true, please stress this also in introduction.

OK.
> 
> 
> 6.2.  Perils of Explicit Identifiers
> 
> 
> *** this section is the core of the motivation of the reccomendation
> in the following chapter. I would name it consequently, or make it
> clearer its role in the title.

I think the title is appropriate; I've promoted to a top-level section.

> 
> 7.  Recommendations
> 
> 
> From these principles, several recommendations can be made:
> 
> 
> o  Systems needing to perform service identification must examine 
> existing signaling constructs to identify the service based on fields
> that exist within the signaling message already.
> 
> 
> o  If it appears that the signaling currently defined in standards is
>  not sufficient to identify the service, it may be due to lack of 
> sufficient signaling to convey what is needed, and new standards work
> should be undertaken to fill this gap.
> 
> 
> o  The usage of an explicit service identifier does make sense as a 
> way to cache a decision made by a network element, for usage by 
> another network element within the same domain.  However, service 
> identifiers are fundamentally useful within a particular domain, and
> any such header must be stripped at a network boundary.
> 
> 
> *** ok see above.
> 
> 


Thanks for your comments!

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[e-mail]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com
_______________________________________________
Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP