[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-sip-publish

Internet Engineering Task Force                            Brian Stucker
Internet Draft                                     Nortel Networks, Inc.
Category: Standards Track                                  November 2001
                                                        Expires May 2002
                                      <draft-stucker-sip-publish-00.txt>


                 SIP-Specific Network Service Publishing

Status of this Memo

     This document is an Internet-Draft and is in full conformance
     with all provisions of Section 10 of RFC2026.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups. Note that
     other groups may also distribute working documents as
     Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time. It is inappropriate to use Internet-Drafts
     as reference material or cite them other than as "work in
     progress".

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/lid-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html

     This document is an individual submission to the IETF. Comments
     should be directed to the authors.

Abstract

     This document describes an extension to the Session Initiation
     Protocol (SIP). The purpose of this extension is to create a means
     for publishing and retrieving information regarding services in the
     network by using SIP.

     The methods described in this document allow a framework by which
     arbitrary service data can be transported into the network for
     use by services running in the network. It is not intended to be
     a general-purpose mechanism for transport of arbitrary data as
     there are better suited mechanisms for this purpose (ftp, etc.),
     but is intended to be a simple, light-weight, mechanism that
     employs SIP in order to support SIP-related services. It is
     envisioned that each service that employs this method may
     extend and provide more detail as to how that service interacts
     with the mechanisms put forth in this draft.



Stucker                                                       [Page 1]

Internet Draft                  DATA method            November 12, 2001


1. Table of Contents



   2          Introduction ........................................    2
   2.1        Overview of Operation................................    3
   3.         Syntax...............................................    3
   3.1        New Methods..........................................    3
   3.2        New Headers..........................................    5
   3.2.1      "Action" Header......................................    5
   3.2.2      "Service" Header.....................................    5
   3.3        The DATA Method......................................    6
   3.4        Usage of the Service Header..........................    7
   3.5        Usage of the Action Header...........................    8
   3.5.1      The PUT Action.......................................    8
   3.5.2      The GET Action.......................................    9
   3.5.3      The DELETE Action....................................    9
   4.         Security Considerations..............................    9
   4.1        Authentication.......................................   10
   4.2        Authorization........................................   10
   5.         Statefulness of Service Data.........................   10
   5.1        Soft Stated Service Data.............................   11
   5.2        Hard Stated Service Data.............................   11
   6.         Error Cases..........................................   11
   6.1        Authorization or Authentication Failure..............   11
   6.2        Service Location Failure.............................   12
   6.3        Wrong Data Format....................................   13
   6.4        Unsupported Action...................................   14
   7.         Extensibility of Actions.............................   14
   8.         Proof of Concept Example - Presence..................   16
   8.1        Message Details......................................   17
   9.         Compatibility with Proxies...........................   23
   10.        Why use SIP?.........................................   23
   9.         References...........................................   25
   10.        Acknowledgements.....................................   25
   11.        Author's Address.....................................   25















Stucker                                                       [Page 2]

Internet Draft                  DATA method            November 12, 2001


2. Introduction


     The ability for a user to push data into the network has already
     shown its usefulness. In the case of CPL and presence, both
     require client devices to publish information regarding how
     services should behave, based on data pushed into the network.

     However, the mechanism that is used to place data into the network
     has not been well defined up to this point, and problems exist
     with the current ad-hoc approach of using the REGISTER method to
     do so.

     Therefore, this document describes a new method that creates a
     framework by which arbitrarty service data can be transported into
     the network for use by services. An example of this would be
     CPL scripting documents, or presence documents. It is not intended
     to be a general-purpose (non-SIP) data transport as there are
     better suited mechanisms for this purpose (ftp, etc.)

     Meeting the data publication requirements for the general problem
     domain of how to transport any given piece of data between two SIP
     endpoints is not possible. The goal of this draft is to provide a
     SIP-specific framework that allows simple pieces of client data to
     be transported into the network for a specific, SIP-related,
     purpose. An example of such a purpose would be to transport CPL
     script data into the network for a CPL call routing service to
     handle SIP intiated calls appropriately.

     SIP is chosen as the transport protocol because the services that
     this mechanism applies to are services created by way of using SIP.
     Where SIP is not the mechanism by which a service is provided, the
     use of the mechanisms described in this draft should be thought out
     very carefully.

     The framework described in this draft does not outline an extension
     which may be used directly. It is intended to be extensible, again,
     because the needs of different services whose data may need to be
     publish can vary. Each data type that intends to use this mechanism
     is responsible for defining the complete set of rules as to how
     this mechanism is to behave. This draft simply sets the framework
     for this to occur. Guidelines and requirements as to how these
     extensions must behave and requirements about their definition are
     described in later sections of this draft.







Stucker                                                       [Page 3]

Internet Draft                  DATA method            November 12, 2001


2.1. Overview of Operation

     The concept of this draft is that entities in the network can
     notify a resource of changes in their configuration data. Whereas
     the generalized subscribe-notify framework is used to synchronize
     two finite state machines, synchronization of data across multiple
     nodes can be viewed as an event notification. Whenever the data
     changes at one end, it simply notifies the other side of the
     change.


     A typical flow of messages to push data to a service would be:

     Data Source              Service
       |------------DATA-------->| Provide or change service data
       |<-----------200----------|

     Data may be hard-stated, and if so, must be refreshed in exactly
     the same manner as registrations (see RFC 2543 [1] ).


3. Syntax

     This section describes the syntax extensions required for data
     notification in SIP. Semantics are described in section 4.

3.1. New Methods

     This document describes one new SIP method: "DATA."

     This table expands on tables 4 and 5 in RFC 2543 [1] .

     Header                    Where    DATA
     ------                    -----    ---
     Accept                      R       o
     Accept-Encoding             R       o
     Accept-Language             R       o
     Action                     Rr       m
     Action                    400       -
     Alert-Info                  g       -
     Allow                      Rr       o
     Allow                      405      m
     Authentication-Info        2xx      o
     Authorization               R       o
     Call-ID                     c       m
     Call-Info                           o





Stucker                                                       [Page 4]

Internet Draft                  DATA method            November 12, 2001


     Header                    Where    DATA
     ------                    -----    ---
     Contact                     R       m
     Contact               1xx, 485      o
     Contact               2xx, 3xx      m
     Content-Disposition                 o
     Content-Encoding                    o
     Content-Length                      o
     Content-Type                        m
     CSeq                        c       m
     Date                                o
     Encryption                  g       o
     Expires                     g       o
     From                        c       m
     In-Reply-To                 R       -
     Max-Forwards                R       o
     Organization                g       o
     Priority                    R       -
     Proxy-Authenticate         407      m
     Proxy-Authorization         R       o
     Proxy-Require               R       o
     Record-Route                R       o
     Record-Route    2xx, 481, 484       o
     Require                     g       o
     Retry-After     404, 413, 480       o
     Retry-After     486, 500, 503       o
     Retry-After          600, 603       o
     Route                       R       o
     Server                      r       o
     Service                     R       m
     Service                     r       o
     Subject                     R       o
     Suppported                          o
     Timestamp                           o
     To                        gc(1)     m
     Unsupported                420      o
     User-Agent                          o
     Via                         c       m
     Warning                     r       o
     WWW-Authenticate           401      m











Stucker                                                       [Page 5]

Internet Draft                  DATA method            November 12, 2001



3.2 New Headers

     This table expands on tables 4 and 5 in RFC 2543 [1] , as amended
     by the changes described in section 3.1.

     Header field         where  proxy ACK BYE CAN INV OPT REG DAT
     -----------------------------------------------------------------
     Action                                     R               -   -   -   -   -   -   m
     Service                g           -   -   -   -   -   -   m


3.2.1. "Action" header

     The following header is defined for the purposes of this
     specification.

     Action            =  ( "Action" ) ":" action-type
                          *( "," SP action-type )
     action-type       =  ( "Get" | "Put" | "Delete" )
                          *("." action-subtype )
     action-subtype    =  token-nodot
     token-nodot       =  1*( alphanum | "-"  | "!" | "%" | "*"
                              | "_" | "+" | "`" | "'" | "~" )


     Action is added to the definition of the element "request-header"
     in the SIP message grammar.

     This document does not define values for action-subtypes. These
     values will be defined by individual event packages, and MUST be
     registered with the IANA.

     There must be exactly one action type listed per action header.
     Multiple actions per message are disallowed except in error
     responses where the supported actions are listed.

3.2.2. "Service" header

     The following header is defined for the purposes of this
     specification.

     Service           =  ( "Service" ) ":" service-tag
                          *( "," SP service-tag )
     service-tag       =  token-nodot
     token-nodot       =  1*( alphanum | "-"  | "!" | "%" | "*"
                              | "_" | "+" | "`" | "'" | "~" )




Stucker                                                       [Page 6]

Internet Draft                  DATA method            November 12, 2001



     Service is added to the definition of the element "general-header"
     in the SIP message grammar.

     This document does not define values for service. These values will
     be defined by individual event packages, and MUST be registered
     with the IANA.

     There must be exactly one service type listed per action header.
     Multiple services per message are disallowed except in error
     responses where the supported services are listed.

3.3. The DATA method

     The DATA method is used to provide a mechanism for publishing data
     into the network. This is done on a domain basis, and follows the
     formatting, and routing rules used for the REGISTER method.

     When the DATA method is routed to the server responsible for the
     domain listed in the requestURI, that server checks the Service
     header, and may modify the requestURI so that the message is
     then forwarded to the correct machine for that service, or may
     process the message immediately instead.

     Example:

        DATA foo.com SIP/2.0
        Via: SIP/2.0/UDP pc.foo.com
        To: sip:A@foo.com
        From: sip:A@foo.com;tag=123
        Service: cpl
        Action: put
        Call-ID: 9876@pc.foo.com
        CSeq: 1288 DATA
        Contact: sip:B@pc.foo.com
        Content-Type: application/cpl+xml
        Content-Length: ...

        <cpl>
           <incoming>
                  <location url="sip:meadams@47.102.21.11:5060">
                     <redirect permanent="no" />
                  </location>
           </incoming>
        </cpl>






Stucker                                                       [Page 7]

Internet Draft                  DATA method            November 12, 2001



        A@foo.com    proxy bar.com    proxy foo.com registrar foo.com
           |----DATA----->|                 |                |
           |              |------DATA------>|                |
           |              |                 |------DATA----->|
           |              |                 |<-----200-------|
           |              |<-----200--------|                |
           |<---200-------|                 |                |


     In the example shown above, since the "bar.com" proxy was not the
     definitive controller for "foo.com" the DATA message was forwarded
     (just like a REGISTER would be). However, once the DATA message
     hit the proxy at "foo.com" the proxy there was the definitive
     controller for "foo.com", but forwarded the message anyhow. This is
     allowed because that proxy may not have had the registrar, where
     "foo.com" handles cpl information co-located. Therefore the proxy
     was able to forward the DATA message on to the server that was
     handling the cpl service for "foo.com". This is allowed.

     Once a DATA message gets to a server within the domain listed in
     the requestURI, one additional forwarding of the message is allowed
     in order to route to a server handling the service described in the
     Service header to cover the case that the service is not co-located
     with the inbound server for that domain. The requestURI MAY be
     changed in order to facilitate this routing, but only by a server
     in the domain that was listed in the original DATA message.

3.4  Usage of the Service Header

     The Service header in the DATA message is used to denote the
     service for which the data being acted upon resides within. Each
     service MUST define and register with IANA it's own service tag
     to be placed in this header. Service tags used in this document
     are for example only, and have not necessarily been registered
     with IANA.

     Servers within the domain listed in the request URI of the DATA
     message MUST inspect the contents of this header to see if the
     service specified is hosted on that machine. If it is not, the
     DATA message may be forwarded (within the same domain) in order
     to reach the correct service hosting the service specified.

     Authors registering new service tags SHOULD pick service tags
     that as closely mimic the MIME type value for their data where
     the MIME type is unambiguous to the service the data is for.





Stucker                                                       [Page 8]

Internet Draft                  DATA method            November 12, 2001


     For instance, if your service's data MIME type is
     application/voicemail+xml, a good basis for a service tag
     would be "voicemail" since it forms an identifiable portion of
     the MIME type header. If the service in question reuses a
     generic MIME type, the service tag should be descriptive of
     the service, and not the MIME type. You should always be
     able to look at the service tag and easily figure out what
     service it refers to.

3.5  Usage of the Action Header

     The Action header in the DATA message is used to denote what
     the service should do, at a minimum, upon receiving the DATA
     message. Three default values are defined, of which the actual
     operation of each is dependent on the particular service.

     Actions may be sub-typed as well, so that a service can
     define a sub-action called "put.merge" in order to have the
     data merged via rules specific to that service instead of simply
     overwritten by use of the "put" action. It is up to each service
     to decide how the data will be processed according to the action
     specified, including the operation of the three defaul values
     specified in this draft.

3.5.1 The PUT Action

     The PUT action is used to associate the resource identified
     within the message body of the DATA message with the TO party
     and service specified in the DATA message. It is modeled on the
     HTTP/1.1 PUT method, and acts as such. Services, generally, will
     take the data in the message body and apply it to the user
     identified in the TO header (similar to a REGISTER message) for
     the service specified in the Service header.

     The result of this operation is denoted by the response to the
     DATA message, where 200 OK always denotes that the operation
     requested succeeeded. Other return values may include a warning
     header or explaination in the reason code as to why the operation
     failed. 4xx, 5xx, and 6xx return codes should always denote
     failure of the operation requested.

     Using a DATA (PUT) message that contains no message body MUST NOT
     be used in lieu of sending a DATA (DELETE) message, as this can
     cause information used to filter the data to be deleted to be
     confused with information to be stored for the resource identified
     in the DATA message.





Stucker                                                       [Page 9]

Internet Draft                  DATA method            November 12, 2001



3.5.2 The GET Action

     The GET action is used to retrieve the data for the resource
     identified within the message body of the DATA message with the
     TO party and service specified in the DATA message. It is modeled
     on the HTTP/1.1 GET method, and acts as such. The message body of
     the DATA (GET) message may contain information used to filter
     which service data is to be returned. For example, a service
     may define message body elements to denote which version of a
     piece of service data is to be returned by sending a last-modified
     timestamp. Normally, the message body of a DATA (GET) message is
     expected to be empty, however.

     The result of this operation is denoted by the response to the
     DATA message, where 200 OK always denotes that the operation
     requested succeeded. The data requested is returned in the message
     body of the response to the DATA (GET) request, and absence of data
     does not imply that the request failed. The value of the response
     code should always be used to determine success or failure of the
     get action. 4xx, 5xx, and 6xx return codes should always denote
     failure of the operation requested (even if data is present in the
     message body of these responses).

3.5.3 The DELETE Action

     The DELETE action is used to delete the data for the resource
     identified within the message body of the DATA message with the
     TO party and service specified in the DATA message. It is modeled
     on the HTTP/1.1 DELETE method, and acts as such. The message body
     of the DATA (DELETE) message may contain information used to filter
     which service data is to be deleted, and MUST NOT be ambiguous. For
     example, a service may define message body elements to denote which
     portions of the service data is to be deleted by using a timestamp
     to delete information before the date noted.

     The result of this operation is denoted by the response to the
     DATA message, where 200 OK always denotes that the operation
     request succeeded. An indication of what data was deleted MAY be
     included in the message body of the response, if so desired by the
     service. The value of the response code should always be used to
     determine success or failure of the delete action. 4xx, 5xx, and
     6xx return codes should always denote failure of the operation
     requested (even if data is present in the message body of these
     responses).


4. Security Considerations



Stucker                                                      [Page 10]

Internet Draft                  DATA method            November 12, 2001


4.1 Authentication

     Since the data contained in a DATA message can be potentially
     sensitive in nature, it is STRONGLY RECOMMENDED that all DATA
     messages be authenticated as to their source. Additionally, it is
     RECOMMENDED that they be encrypted. The extent to which SIP is
     used is up to the implementor as various transport protocols
     (such as TLS) can mitigate the need to add additional protection
     using SIP. However, SIP authentication SHOULD be part of any
     authentication scheme for service data since the service data is
     part of the SIP service space. Usage of HTTP Basic authentication
     is NOT RECOMMENDED.

4.2 Authorization

     In order to support third-party service data (much like third-party
     registrations), the content of the TO header identifies the
     resource that the data in the message body (or action) is to be
     applied. In the case where TO and the FROM headers describe
     different parties, the FROM party must be authorized prior to the
     sending of the DATA message to take action on the TO party's
     service data. The means by which this authorization takes place
     is outside the scope of this document.

     If the network wishes to conceal whether or not an update to the
     service data has succeeded or not, when a third-party is involved,
     it may send back a 200 response to the request, even though the
     request has failed. It should be stressed however, that such
     operation should be used sparingly, and only in scenarios where
     notifying the third party that the request failed would reveal
     information that could be used in an attack on the network or
     TO party of the request. This follows the third-party registration
     model already in SIP [1].

5. Statefulness of Service Data

     Service data may be soft-stated (expires after a specified period
     of time) or hard-stated (does not expire until modified
     explicitly). In order to support both models of statefulness, the
     presence or absence of an Expires header in the DATA message is
     utilized.

     Mixed statefulness of data for the same service in the same
     request is undefined. If a service contains information that is
     both hard-stated and soft-stated, requests and responses must
     be crafted such that information can be kept separate unless
     such statefulness is identifiable within the message body itself.




Stucker                                                      [Page 11]

Internet Draft                  DATA method            November 12, 2001


5.1 Soft-Stated Service Data

     Soft-stated service data is denoted by inclusion of an Expires
     header specifying the interval of time the data is to be considered
     valid. If an Expires value is set in the DATA request, it MUST be
     included in the response. The expires interval in the request may
     decreased by the service provider. The actual interval that the
     service data will be valid for MUST BE INCLUDED in the response.

     Requests including an Expires header MUST NOT request an interval
     smaller than 60 seconds for the data to be valid.

     An Expires header MUST NOT be included in a request containing
     a GET or DELETE action (or an sub-typed action derived from these
     actions). Responses to a GET MAY contain an Expires header to show
     the remaining amount of time soft-stated service data may be
     valid for. Responses to a DELETE action MUST NOT contain an Expires
     header.

5.2 Hard-Stated Service Data

     Hard-stated service data is denoted by NOT including an Expires
     header in the request. Service data contained in such requests
     SHOULD remain valid until replaced or removed. Responses to
     requests containing hard-stated data should likewise not contain
     an Expires header.

     Statefulness for the DELETE action is defined to be hard-stated
     since completion of the action removes any material that could
     be soft-stated. Responses to a DELETE action should therefore
     always be considered hard-stated, and not contain an Expires
     header.

     Statefulness for the GET action is defined to be both soft-stated
     and hard-stated. Requests with a GET action are considered hard-
     stated, but responses MAY or MAY NOT contain an Expires header
     depending on the statefullness of the data retrieved. If the
     data retrieved is hard-stated, an Expires header should not
     be included in the response.

6. Error Cases

6.1 Authorization or Authentication Failure

     Errors arising from authorization or authentication failures should
     be handled according to the rules for the REGISTER method defined
     within SIP.




Stucker                                                      [Page 12]

Internet Draft                  DATA method            November 12, 2001


6.2 Service Location Failure

     In the case that a service is not located, it is possible to return
     the known set of services that are supported for data publication
     in the response. This is done by including the list in the
     Service header returned in the response to the request. The response
     MUST NOT contain the Action header.

     Example:

        DATA foo.com SIP/2.0
        Via: SIP/2.0/UDP pc.foo.com
        To: sip:A@foo.com
        From: sip:A@foo.com;tag=123
        Service: cpl
        Action: put
        Call-ID: 9876@pc.foo.com
        CSeq: 1288 DATA
        Contact: sip:B@pc.foo.com
        Content-Type: application/cpl+xml
        Content-Length: ...

        <cpl>
           <incoming>
                  <location url="sip:meadams@47.102.21.11:5060">
                     <redirect permanent="no" />
                  </location>
           </incoming>
        </cpl>


        SIP/2.0 400 Service Not Supported
        Via: SIP/2.0/UDP pc.foo.com
        To: sip:A@foo.com
        From: sip:A@foo.com;tag=123
        Service: presence, voicemail
        Call-ID: 9876@pc.foo.com
        CSeq: 1288 DATA
        Contact: sip:B@pc.foo.com
        Content-Length: 0











Stucker                                                      [Page 13]

Internet Draft                  DATA method            November 12, 2001


6.3 Wrong Data Format

    If the service is known, but the data supplied is not formatted
    according to the requirements of that service, an error response
    SHOULD be generated for the request using a 415 Unsupported Media
    Type, identifying the accepted formats using the Accept, Accept-
    Encoding, and Accept-Language headers.

     Example:

        DATA foo.com SIP/2.0
        Via: SIP/2.0/UDP pc.foo.com
        To: sip:A@foo.com
        From: sip:A@foo.com;tag=123
        Service: presence
        Action: put
        Call-ID: 9876@pc.foo.com
        CSeq: 1288 DATA
        Contact: sip:B@pc.foo.com
        Content-Type: application/cpl+xml
        Content-Length: ...

        <cpl>
           <incoming>
                  <location url="sip:meadams@47.102.21.11:5060">
                     <redirect permanent="no" />
                  </location>
           </incoming>
        </cpl>


        SIP/2.0 415 Unsupported Media Type
        Via: SIP/2.0/UDP pc.foo.com
        To: sip:A@foo.com
        From: sip:A@foo.com;tag=123
        Service: presence
        Action: put
        Call-ID: 9876@pc.foo.com
        CSeq: 1288 DATA
        Contact: sip:B@pc.foo.com
        Content-Length: 0
        Accept: application/cpim+pidf









Stucker                                                      [Page 14]

Internet Draft                  DATA method            November 12, 2001


6.4 Unsupported Action

    If the service identified does not support the requested action, an
    error SHOULD be generated. In this case a 400 response is used to
    denote a failure in the syntax of the request. Since the Action is
    the incorrect header, the Service header MUST NOT be included. This
    is done in order to make it clear which header was in error.

     Example:

        DATA foo.com SIP/2.0
        Via: SIP/2.0/UDP pc.foo.com
        To: sip:A@foo.com
        From: sip:A@foo.com;tag=123
        Service: cpl
        Action: put.merge
        Call-ID: 9876@pc.foo.com
        CSeq: 1288 DATA
        Contact: sip:B@pc.foo.com
        Content-Type: application/cpl+xml
        Content-Length: ...

        <cpl>
           <incoming>
                  <location url="sip:meadams@47.102.21.11:5060">
                     <redirect permanent="no" />
                  </location>
           </incoming>
        </cpl>


        SIP/2.0 400 Unsupported Action
        Via: SIP/2.0/UDP pc.foo.com
        To: sip:A@foo.com
        From: sip:A@foo.com;tag=123
        Action: put, get, delete
        Call-ID: 9876@pc.foo.com
        CSeq: 1288 DATA
        Contact: sip:B@pc.foo.com
        Content-Length: 0

7. Extensibility of Actions

     Services may extend the basic action values of PUT, GET, and
     DELETE for their purposes. Extending these should be done only
     when specifying the correct action to take would be difficult
     using the contents of the message body.




Stucker                                                      [Page 15]

Internet Draft                  DATA method            November 12, 2001



     Such extensions are denoted by a ".extension". For instance, if
     an append action were desired for a service data operation,
     the extended action would be "put.append", etc.

     Extensions should not violate the basic operation of the base
     action. For instance, "delete.append" would not be considered
     a valid extension because to append is to add, which is counter
     to the base action "delete" which is to remove.

     Extensions must be defined explicitly for each of the basic
     actions. Defining a sub-action type for one action does not
     define it for all other action types. This may result in
     simply stating that the sub-action type is not defined for
     a given basic action.

     Example:

        In order to define the append sub-action, you might state:

        put.append - Appends data onto the bottom of the already
                     existing service data.

        get.append - Unsupported.

        delete.append - Unsupported.


    Example:

        In orde to define that actions should take into account
        the Date header of the request, you might state:

        put.date - Overwrites service data older than the date
                   specified in the request.

        get.date - Retrieves service data newer than the date
                   specified in the request.

        delete.date - Deletes service data older than the date
                      specified in the request.



     Note, that any such sub-actions would need to be registered with
     IANA to ensure that the namespace for the action header is
     coordinated. This would be done as part of defining a service
     specific publication package based on this draft.



Stucker                                                      [Page 16]

Internet Draft                  DATA method            November 12, 2001


8. Proof of Concept Example - Presence

     In order to provide a proof of concept example to help illustrate
     how the DATA method would work with a real-world application, the
     following section gives an example of how DATA could be used to
     publish presence documents according to the framework of the
     SIMPLE draft. The exact rules of how the presence service would
     handle each of the actions for DATA would need to be further
     specified in a separate draft. Depending on those rules, and
     policy uploaded by the user, the actual messaging outcomes may
     vary from what is put forth here. This section is for
     demonstration only.

                        Presence
     Watcher             Server                 PUA
        |    SUBSCRIBE      |                    |
        |------------------>|                    |
        |    200 OK         |                    |
        |<------------------|                    |
        |    NOTIFY         |                    |
        |<------------------|                    |
        |    200 OK         |                    |
        |------------------>|                    |
        |                   |                    |
        |                   |   F1 DATA          |
        |                   |<-------------------|
        |                   |   F2 200 OK        |
        |                   |------------------->|
        | F3 NOTIFY         |                    |
        |<------------------|                    |
        | F4 200 OK         |                    |
        |------------------>|   F5 DATA          |
        |                   |<-------------------|
        |                   |   F6 200 OK        |
        |                   |------------------->|
        | F7 NOTIFY         |                    |
        |<------------------|                    |
        | F8 200 OK         |                    |
        |------------------>|                    |
        |                   |   F9 REGISTER      |
        |                   |<-------------------|
        |                   |   F10 200 OK       |
        |                   |------------------->|
        | F11 NOTIFY        |                    |
        |<------------------|                    |
        | F12 200 OK        |                    |
        |------------------>|                    |




Stucker                                                      [Page 17]

Internet Draft                  DATA method            November 12, 2001


8.1 Message Details



     F1 DATA   PUA->presence server


      DATA sip:example.com SIP/2.0
      Via: SIP/2.0/UDP pua.example.com:5060
      To: <sip:userA@example.com>
      From: <sip:userA@example.com>;tag=1234
      Call-ID: 9876@pua.example.com
      CSeq: 1 DATA
      Service: presence
      Action: put
      Accept: application/cpim-pidf+xml
      Contact: <sip:userA@pua.example.com>

      <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
         <tuple name="im-1">
           <status>
             <value>open</value>
             <detail type="im"
              schema="http://www.ietf.org/dtd/im-type-im.dtd">available</detail>
           </status>
           <contact priority="2">im:userA@pua.example.com</contact>
         </tuple>
      </presence>


     F2 200 OK   presence server->PUA

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP pua.example.com:5060
      To: <sip:userA@example.com>;tag=abcd
      From: <sip:userA@example.com>;tag=1234
      Call-ID: 9876@pua.example.com
      CSeq: 1 DATA
      Contact: sip:example.com












Stucker                                                      [Page 18]

Internet Draft                  DATA method            November 12, 2001


     F3 NOTIFY  presence server-> watcher

      NOTIFY sip:userB@watcherhost.example.com SIP/2.0
      Via: SIP/2.0/UDP presence.example.com:5060
      From: <sip:userA@example.com>;tag=ffd2
      To: <sip:userB@example.com>;tag=xfg9
      Call-ID: 192837@presence.example.com
      CSeq: 1 NOTIFY
      Event: presence
      Content-Type: application/cpim-pidf+xml
      Content-Length: ..

      <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
         <tuple name="im-1">
           <status>
             <value>open</value>
             <detail type="im"
              schema="http://www.ietf.org/dtd/im-type-im.dtd">available</detail>
           </status>
           <contact priority="2">im:userA@pua.example.com</contact>
         </tuple>
      </presence>


     F4 200 OK

      Via: SIP/2.0/UDP presence.example.com:5060
      From: <sip:userA@example.com>;tag=ffd2
      To: <sip:userB@example.com>;tag=xfg9
      Call-ID: 192837@presence.example.com
      CSeq: 1 NOTIFY




















Stucker                                                      [Page 19]

Internet Draft                  DATA method            November 12, 2001


     F5 DATA   PUA->presence server


      DATA sip:example.com SIP/2.0
      Via: SIP/2.0/UDP pua.example.com:5060
      To: <sip:userA@example.com>
      From: <sip:userA@example.com>;tag=1234
      Call-ID: 9876@pua.example.com
      CSeq: 2 DATA
      Service: presence
      Action: delete
      Accept: application/cpim-pidf+xml
      Contact: <sip:userA@pua.example.com>

      <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
         <tuple name="im-1">
           <status>
             <value>open</value>
           </status>
         </tuple>
      </presence>


     F6 200 OK   presence server->PUA

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP pua.example.com:5060
      To: <sip:userA@example.com>;tag=abcd
      From: <sip:userA@example.com>;tag=1234
      Call-ID: 9876@pua.example.com
      CSeq: 2 DATA
      Contact: sip:example.com



















Stucker                                                      [Page 20]

Internet Draft                  DATA method            November 12, 2001


     F7 NOTIFY  presence server-> watcher

      NOTIFY sip:userB@watcherhost.example.com SIP/2.0
      Via: SIP/2.0/UDP presence.example.com:5060
      From: <sip:userA@example.com>;tag=ffd2
      To: <sip:userB@example.com>;tag=xfg9
      Call-ID: 192837@presence.example.com
      CSeq: 2 NOTIFY
      Event: presence
      Content-Type: application/cpim-pidf+xml
      Content-Length: ..

      <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
         <tuple name="im-1">
           <status>
             <value>open</value>
           </status>
           <contact priority="2">im:userA@example.com</contact>
         </tuple>
      </presence>


     F8 200 OK

      Via: SIP/2.0/UDP presence.example.com:5060
      From: <sip:userA@example.com>;tag=ffd2
      To: <sip:userB@example.com>;tag=xfg9
      Call-ID: 192837@presence.example.com
      CSeq: 2 NOTIFY

     F9  REGISTER  PUA->registrar/presence server

      REGISTER sip:example.com SIP/2.0
      Via: SIP/2.0/UDP pua.example.com:5060
      To: <sip:userA@example.com>
      From: <sip:userA@example.com>
      Call-ID: 234897@pua.example.com
      CSeq: 2 REGISTER
      Contact: <sip:userA@pua.example.com>
      Expires: 0











Stucker                                                      [Page 21]

Internet Draft                  DATA method            November 12, 2001


     F10  200 OK    registrar/presence server->PUA

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP pua.example.com:5060
      To: <sip:userA@example.com>
      From: <sip:userA@example.com>
      Call-ID: 234897@pua.example.com
      CSeq: 2 REGISTER

     F11 NOTIFY  presence server-> watcher

      NOTIFY sip:userB@watcherhost.example.com SIP/2.0
      Via: SIP/2.0/UDP presence.example.com:5060
      From: <sip:userA@example.com>;tag=ffd2
      To: <sip:userB@example.com>;tag=xfg9
      Call-ID: 192837@presence.example.com
      CSeq: 3 NOTIFY
      Event: presence
      Content-Type: application/cpim-pidf+xml
      Content-Length: ..

      <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
         <tuple name="im-1">
           <status>
             <value>closed</value>
           </status>
           <contact priority="2">im:userA@example.com</contact>
         </tuple>
      </presence>


     F12 200 OK

      Via: SIP/2.0/UDP presence.example.com:5060
      From: <sip:userA@example.com>;tag=ffd2
      To: <sip:userB@example.com>;tag=xfg9
      Call-ID: 192837@presence.example.com
      CSeq: 3 NOTIFY













Stucker                                                      [Page 22]

Internet Draft                  DATA method            November 12, 2001


9. Compatibility with Proxies

     Because the DATA method shares the same routing rules as a REGISTER
     method message, in general, the routing of a DATA message is
     compatible with the current (bis-05) routing rules contained in
     SIP [1].

     In particular, a stateless proxy is allowed to inspect the service
     header in order to determine the next hop the message should take.
     This is allowed for in SIP. However, should a stateless proxy
     be the definitive domain controller for a given domain, the DATA
     message may be forwarded an additional time (if needed), instead
     of the one-more-hop rule stated earlier. Should the stateless
     proxy forward to another stateless proxy, an additional hop is
     again allowed until the DATA message reaches the correct server
     to process the request, or reaches a stateful proxy server.

     This follows the routing rules set forth in section 16 of (bis-05)
     SIP.

10.  Why use SIP?

     There are several arguments for using SIP as a mechanism by which
     to publish generic service information.

     First, there are already several such mechanisms defined
     within SIP. The REGISTER method is used to publish contact
     information for network routing services. It is possible to use
     SIP quite well, without the use of the REGISTER message; at the
     cost that there is no network based routing. Thus, in order for
     network based routing services to work, a mechanism for
     publishing information into the SIP network must be supported:
     hence REGISTER.

     Another well-known method of publishing service data is the
     SUBSCRIBE-NOTIFY framework. There are a number of event packages
     including presence, watcherinfo, REFER, and voicemail that have
     defined message bodies to support the transport of service
     information via SIP.

     Finally, SIP itself is designed to be open for service data
     transport. Nearly any message sent using SIP is allowed to
     contain a message body. It is the very rare case that the
     message body MUST be empty, and the content-type header is
     very rarely excluded from any given method defined for SIP.






Stucker                                                      [Page 23]

Internet Draft                  DATA method            November 12, 2001


     The common thread here, though, is that data that is transported
     is *directly related* to the service space created by SIP. This
     is done, presumably, to make the protocol simpler to understand
     by limiting the number of transports, and easier to implement
     (again, by using a common protocol). By inspection of the
     SIP RFC, and the many drafts and extensions that have been
     created since, the conclusion, therefore, can be made that
     using SIP to carry service specific information, for services
     defined in the SIP space (not any arbitrary service), is
     appropriate.









































Stucker                                                      [Page 24]

Internet Draft                  DATA method            November 12, 2001

11. References

     [1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP:
         Session Initiation Protocol", RFC 2543, IETF; March 1999.

     [2] A. Roach, "SIP-Specific Event Notification", <draft-
         ietf-sip-events-01.txt>, IETF; November 2001. Work in
         progress.

     [3] R. Fielding et. al., "Hypertext Transfer Protocol --
         HTTP/1.1", RFC2068, IETF, January 1997.

     [4] S. Donovan, "Requirements for Publication of SIP
         Related Service Data", <draft-donovan-publish-
         requirements-00.txt>, September 2001. Work in progress.

     [5] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of
         SIP Extensions", RFC Guidelines, March  2001.

     [6] Rosenberg, J., et. al., "SIP Extensions for Presence",
         draft-ietf-simple-presence-03.txt, September 2001.
         Work in pregress.

     [7] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg/
         G. Camarillo/A. Johnston/J. Peterson/R. Sparks/E. Schooler,
         "SIP: Session Initiation Protocol", <draft-ietf-sip-
         rfc2543bis-05.txt>, October 2001. Work in Progress.


12. Acknowledgements

     The author wishes to thank Steve Donovan for a thorough
     presentation of service data publication requirements, as well
     as Jennifer Beckman, Trip Ingle, Alex Nava, Mary Barnes,
     and Sriram Parameswar for various guidance and support in
     the creation of this draft.

13. Author's Address

     Brian Stucker
     Nortel Networks, Inc.
     2375-B Glenville Rd.
     Richardson, TX 75082
     USA
     Phone: +1 972 685 7724
     Fax: +1 972 685 3653
     E-Mail: bstucker@nortelnetworks.com





Stucker                                                      [Page 25]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/