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

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.

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.

    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.

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

       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.

    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.



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.

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

*** 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?

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.

    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.

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.

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.

































Rosenberg               Expires February 2, 2008               [Page 19]

Internet-Draft                 Service ID                    August 2007


Full Copyright Statement

    Copyright (C) The IETF Trust (2007).

    This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
    retain all their rights.

    This document and the information contained herein are provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.  Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository at
    http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    ietf-ipr@ietf.org.


Acknowledgment

    Funding for the RFC Editor function is provided by the IETF
    Administrative Support Activity (IASA).





Rosenberg               Expires February 2, 2008               [Page 20]


_______________________________________________
APPS-REVIEW mailing list
APPS-REVIEW@ietf.org
https://www1.ietf.org/mailman/listinfo/apps-review