Subject: Re: [Sipping] Review of draft-drage-sipping-service-identification-02

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 23 Mar 2009 15:10:50 +0100

See below for response to comments

Keith 

________________________________

	From: Andrew Allen [mailto:[email-masked]] 
	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.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 23 Mar 2009 15:10:49 +0100

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:[email-masked]] 
	Sent: Tuesday, December 16, 2008 11:05 AM
	To: sipping; DRAGE, Keith (Keith)
	Cc: [email-masked]
	Subject: RE: [Sipping] 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: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Allen
	Sent: 24. november 2008 04:19
	To: sipping; DRAGE, Keith (Keith)
	Subject: [Sipping] Review of draft-drage-sipping-service-identification-02

	Here are my comments

	Abstract

	Proposed Rephrase

	1.	Introduction 

	 

	Add

	      Identifier

	Proposed rewrite:

	Propose add RFC 3840

	4.4 

	      date: 2007-04-21

	5.1.1

	documented in 5.1.1

	Proposed text

	be present.  

	5.1.2

	Proposed text

	6 Examples

	Andrew Allen

	Manager Standards

	Research In Motion Ltd

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 23 Mar 2009 15:10:47 +0100

I have done this on my working version of the document, although I don't think there is anything wrong with the existing examples in this respect. The wording I have adopted does allow direct definition of a service at this level - it just may not do so.

It may however take the examples over the line width and force a line break - may have to change them again if NITS comes up and says that.

regards

Keith

________________________________
From: Atle Monrad [mailto:[email-masked]]
Sent: Tuesday, December 16, 2008 11:14 AM
To: sipping; DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: RE: [Sipping] Review ofdraft-drage-sipping-service-identification-02

I forgot one more issues:

The draft outlines the top level identifiers to be 3gpp-service and 3gpp-application. In order to align with this, I assume that the examples throughout the draft shall be:

P-Asserted/Preferred-Service: urn:urn-xxx:3gpp-service.exampletelephony.version1>
/atle

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Atle Monrad
Sent: 16. desember 2008 12:05
To: sipping; DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: [Sipping] Review ofdraft-drage-sipping-service-identification-02

/atle

Here are my comments

Proposed Rephrase

 1.  Introduction

Add

Proposed rewrite:

Propose add RFC 3840

4.4

5.1.1

Proposed text

5.1.2

Proposed text

6 Examples

Andrew Allen

Manager Standards

Research In Motion Ltd

http://www.rim.com/

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 24 Mar 2009 19:47:30 -0400

On Mon, 2009-03-23 at 15:10 +0100, DRAGE, Keith (Keith) wrote:
> 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. 
> 

Maybe I've missed some discussion, but I don't quite understand the
second component proposed for the URNs.  In -02, it is shown as
"urn-xxx" (with the initial scheme "urn" omitted, which you have since
fixed).  In your message that I am replying to, it is shown as "urn-7",
which seems to be part of a series "urn-N" for defining URNs for local
use.

But given that 3GPP is interested in this, don't they already have a URN
namespace selected?

Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 26 Mar 2009 20:23:06 +0100

Note that the URN in this document has already been through the informal URN review process within IETF and is essentially approved and registered by IANA.

The reason for using a different URN (apart from the fact that this definition was already in flight at the time the 3GPP URN was developed) is that the informal URN in this document carries additional semantics as the the usage that use of the 3GPP URN would not convey.

regards

Keith

> -----Original Message-----
> From: Dale Worley [mailto:[email-masked]] 
> Sent: Tuesday, March 24, 2009 11:48 PM
> To: DRAGE, Keith (Keith)
> Cc: Atle Monrad; sipping
> Subject: Re: [Sipping] Review of 
> draft-drage-sipping-service-identification-02
> 
> Maybe I've missed some discussion, but I don't quite 
> understand the second component proposed for the URNs.  In 
> -02, it is shown as "urn-xxx" (with the initial scheme "urn" 
> omitted, which you have since fixed).  In your message that I 
> am replying to, it is shown as "urn-7", which seems to be 
> part of a series "urn-N" for defining URNs for local use.
> 
> But given that 3GPP is interested in this, don't they already 
> have a URN namespace selected?
> 
> Dale
> 
> 
>