Document: draft-drage-sipping-service-identification-02
Reviewer: Andrew Allen
Review Date: Nov 23, 2008

Summary: On the right track.
 
Comments:
=========


Abstract:
---------

This URN can be used to identify services within the
SIP header fields defined in this document, and also within the
framework defined for caller preferences and callee capabilities in
to identify usage of both services and applications between end UAs.

 

Proposed Rephrase:

This URN can be used within the SIP header fields defined in this document 
to identify services, and also within the framework defined for caller 
preferences and callee capabilities to identify usage of both services and 
applications between end UAs.


 

Introduction:
-------------
 

 P-Asserted-Service: urn-xxx:exampletelephony.version1


Add:

 Note to RFC editor: replace xxx with the assigned 3 numeric digit Identifier

 

4.2.  The P-Preferred-Service Header
-------------------------------------

 

   The P-Preferred-Service header field is used from a user agent to a
   trusted proxy to carry the preferred service of the user sending the
   SIP request that the user wishes to be used for the P-Asserted-
   Service field value that the trusted element will insert.

 

Proposed rewrite:

 
   The P-Preferred-Service header field is used by a user agent 
   sending the SIP request to provide a hint to a trusted proxy of the 
   preferred service that the user wishes to be used for the P-Asserted-
   Service field value that the trusted element will insert.

 

Propose add RFC 3840:
----------------------

 

4.3.  Service and Application Definition

 
   The service and subservice identifiers identify the service as
   described in Section 1.  The URN may also be used to identify a
   service or an application between end users for use within the
    context of RFC 3841 [RFC3841] **and RFC 3840 [RFC3840]**.

 

Update Registration Information:
--------------------------------

 4.4 

   Registration Information:  Registration version: 1; registration
   date: 2007-04-21

 


5.1.1:
-------

There is no text regarding the use of the P-Asserted-Service header by UACs.

 
   A UAC within the trust domain (such as a Media Gateway or Application Server) 
   Can also include a P-Asserted-Service header. This behavior should also be 
   documented in 5.1.1


Proposed text:

   A UAC that is within the same trust domain as the proxy it sends a request to,    (e.g a Media Gateway or Application Server) MAY insert a 
   P-Asserted-Service header in a request that creates a dialog, or a request 
   outside of a dialog. This information MUST NOT conflict with other SIP
   or SDP information included in the request.  Furthermore, the SIP or
   SDP information needed to signal functionality of this service MUST be    present.  

 
5.1.2:
------

There is no text regarding the use of the P-Preferred-Service header by proxies. This needs to be added.

Proposed text:

   When a proxy receives a request containing a P-Preferred-Service header the
   Proxy MAY use the contents of that header to assist in determining the service
   to be included in a P-Asserted-Service header field, (for instance to             prioritize the  order of comparison of filter criteria for potential services     that the request could match). The proxy MUST NOT use the contents of 
   the P-Preferred-Service header to identify the service without first 
   checking against the capabilities (e.g.  SDP) contained in the request. 
   If the proxy inserts a P-Asserted-Service header in the request the    proxy MUST remove the P-Preferred-Service header before forwarding the          request, otherwise the Proxy SHOULD include the P-Preferred-Service 
   header when forwarding the request.
 

6 Examples:
-----------

The text in 6 seems to originate from RFC 3325 and not modified as it seems to relate to P-Asserted-Identity and not P-Asserted-Service

   In this example, proxy.example.com creates a P-Asserted-Service
   header field from the user identity it discovered from SIP Digest
   authentication, and the list of services appropriate to that user,
   and the services that correspond to the SDP information included in
   the request.  It forwards this information to a trusted proxy which
   forwards it to a trusted gateway.  Note that these examples consist
   of partial SIP messages that illustrate only those headers relevant
   to the authenticated identity problem.

The examples themselves seem identity related too with 407 Proxy Authorization which is not related to the functionality in this draft.

Since SDP is the most likely means to determine the service I think this should be shown in the examples

Probably two examples are needed one with P-Preferred-Service and one without. Also I think we should have in one of the examples the  
proxy stripping the P-Asserted-Service header at the edge of the trust domain,