Keith As far as I can see, it looks like the issues that have been raised are covered by the new version. Thanks /atle Atle Monrad Standardisation ST-Ericsson Product Group Mobile Platforms Televeien 1 N-4820, Grimstad Norway www.stericsson.com Office: +47 37 29 30 40 Mobile: +47 45 41 06 65 Fax: +47 37 04 23 70 Email: atle.monrad@xxxxxxxxxxxxxx This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive emails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -----Original Message----- From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of DRAGE, Keith (Keith) Sent: 23. mars 2009 15:11 To: Andrew Allen Cc: sipping Subject: Re: Review ofdraft-drage-sipping-service-identification-02 See below for response to comments Keith ________________________________ From: Andrew Allen [mailto:aallen@xxxxxxx] Sent: Monday, November 24, 2008 3:19 AM To: sipping; DRAGE, Keith (Keith) Subject: Review of draft-drage-sipping-service-identification-02 I have reviewed draft-drage-sipping-service-identification-02 Here are my 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. KED: Incorporated in revised version. ------------------------------------------------------------------------ ------------------------------------------------------------------------ -- 1. Introduction P-Asserted-Service: urn-xxx:exampletelephony.version1 Add Note to RFC editor: replace xxx with the assigned 3 numeric digit Identifier KED: Superceded by preassignment of value for informal URN. ------------------------------------------------------------------------ ------------------------------------------------------------------------ -- 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. KED: included as above. ------------------------------------------------------------------------ ------------------------------------------------------------------------ -- 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]**. KED: included as above. ------------------------------------------------------------------------ ------------------------------------------------------------------------ -- Update Registration Information 4.4 Registration Information: Registration version: 1; registration date: 2007-04-21 KED: Will revise to whatever is in the preregistered IANA registration. ------------------------------------------------------------------------ ------------------------------------------------------------------------ -- 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. KED: Text included as above. ------------------------------------------------------------------------ ------------------------------------------------------------------------ -- 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. KED: Included as written above. ------------------------------------------------------------------------ ------------------------------------------------------------------------ -- 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, KED: I have added some explanation of the authentication to the the examples, clearly identifying that it does not directly form part of the capability. I think the identification of the services the user is entitled to from its identity can form a valid part of identifying the P-Asserted-Service, and this is what the example shows. KED: I have added the SDP. KED: I don't particularly want to add more examples of usage. Yes we do not show the P-Preferred-Service in the examples, but I think the usage of this header field is well defined. Andrew Allen Manager Standards Research In Motion Ltd Office +1 847-793-0861 x20824 BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ <http://www.rim.com/> --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
