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

From: "Atle Monrad" <[email-masked]>
Date: Fri, 3 Apr 2009 01:27:48 +0200

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: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of DRAGE, Keith (Keith)
Sent: 23. mars 2009 15:11
To: Andrew Allen
Cc: sipping
Subject: Re: [Sipping] Review
ofdraft-drage-sipping-service-identification-02

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. 

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP