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

From: "Atle Monrad" <[email-masked]>
Date: Tue, 16 Dec 2008 12:04:59 +0100

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

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Atle Monrad" <[email-masked]>
Date: Tue, 16 Dec 2008 12:13:52 +0100

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

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: "Atle Monrad" <[email-masked]>
Date: Tue, 16 Dec 2008 18:51:33 +0100

One more issue that needs to be addressed:
 
In section 4.4 it is written:

For any given service identifier, labels can be removed right-to-left
and the resulting URN is still valid, referring a more generic service,
with the except of the top-level service identifier and possibly the
first sub-service or sub-application identifier.  In other words, if a
service identifier 'w.x.y.z' exists, the URNs 'w.x' and 'w.x.y' are also
valid service identifiers.

While this is valid for some extensions, it is also clear that to make a
general statement that it is possible to revert bach to the first
sub-service is not always the case. In the example in the current
version of the draft the <exampletelephony.version1> shows how the
version1 cannot be seen as a service on its own. Rather it is possible
to revert back from <exampletelephony.version1> to <exampletlephony> but
not any further. I hope the next version of the draft can correct this
text. I leave to Keith to figure out the detailed text but can offer a
proposal. 
 
For some service identifiers, labels can be removed right-to-left and
the resulting URN is still valid, referring a more generic or basic
service. This can for example apply when a service is customised or a
version-2 is launced.  If a service identifier 'w.x' exists, the URNs
'w.x.y' or 'w.x.y.z' can be valid service identifiers customising the
service 'w.x'. In this case backwards compatibility to the service 'w.x'
can be supported. Labels cannot be removed past a defined basic service.

/atle

Sent: 16. desember 2008 12:14

 

/atle

 

 
 
/atle