In my working copy I have added this to the string in front of the urn definition itself, rather than in 4.1. and 4.2.
Service-ID = "urn:urn-7:" urn-service-id
urn-service-id = top-level *("." sub-service-id)
top-level = let-dig [ *26let-dig ]
sub-service-id = let-dig [ *let-dig ]
let-dig = ALPHA / DIGIT / "-"
regards
Keith
________________________________
From: Atle Monrad [mailto:atle.monrad@xxxxxxxxxxxx]
Sent: Tuesday, December 16, 2008 11:05 AM
To: sipping; DRAGE, Keith (Keith)
Cc: 3GPP_TSG_CT_WG1@xxxxxxxxxxxxx
Subject: RE: Review of draft-drage-sipping-service-identification-02
I have some further comments to the draft that also would be useful to get on board in the next version.
It is my understanding that the P-Preferred-Service and P-Asserted-Service headers shall contain the complete URN. This is also described in the introduction. However, in section 1 and in section 6 of the draft the P-P-S and the P-A-S headers has urn's like <urn-xxx:exampletelephony.version1>. To my understanding the complete urn shall be <urn:urn-xxx:exampletelephony.version1>. In section 6; note also the nit "example-telephony" (the dash shall be removed).
I also assume that section 4.1 and 4.2 also needs to be updated to reflect that the complete URN shall be included in P-P-S and P-A-S headers.
3GPP assumes that the P-P-S and P-A-S headers shall contain the complete urn, thus it is necessary to align the draft.
/atle
________________________________
From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Andrew Allen
Sent: 24. november 2008 04:19
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.
--------------------------------------------------------------------------------------------------------------------------------------------------
1. 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,
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
