|
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. --------------------------------------------------------------------------------------------------------------------------------------------------
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
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
