[Sipping] Open issue#2: draft-drage-sipping-service-identification (P-Preferred)

["DRAGE, Keith \(Keith\)" <[e-mail]>]

Eric Burger had the following comment:

"The mechanisms described in the draft for the P-Asserted-Service makes
sense and is useful.  My only comment with P-Asserted-Service is I would
STRONGLY RECOMMEND an IESG note on the cover of the draft warning of the
dire consequences of relying on the P-Asserted-Service between
administrative domains or between a SIP User Agent Client and the
network.

However, the mechanisms described in the draft for P-Preferred-Service
have no utility and, in fact, may result in harmful behavior.

To wit, consider the following section from the draft:
   5.1.1. Procedures at User Agent Clients (UAC)

   The UAC MAY insert a P-Preferred-Service in a request that creates a
   dialog, or a request outside of a dialog.  This information can
   assist the proxies in identifying appropriate service capabilities to
   apply to the call.  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.  Thus if a service requires a video component, then the
   SDP has to include the media line associated with that video
   component; it cannot be assumed from the P-Preferred-Service header
   field value. Similarly if the service requires particular SIP
   functionality for which a SIP extension and a Require header field
   value is defined, then the request has to include that SIP signalling
   as well as the P-Preferred-Service header field value.


What this says is all of the information required to route the call
(i.e., determine the service) is contained in the INVITE message.
Stated differently, the P-Preferred-Service header PROVIDES NO USEFUL
INFORMATION.
To date, in discussions in the SIPPING Work Group, there have been
virtually no service examples for which the P-Preferred-Service header
adds any information.  In fact, the examples for which the
P-Preferred-Service header added value highlight why this header will be
detrimental to the Internet.
Namely, the use cases where it does add information are cases where the
SIP protocol itself is deficient.

What makes this use detrimental is the P-Preferred-Service approach is,
by definition, proprietary and non-interoperable.  Rather than repairing
or extending the base protocol, this header will encourage "quick fixes"
that do not address the underlying problem.  At that point the
P-Preferred-Service takes on protocol meaning, EVEN OUTSIDE A LIMITED
DOMAIN.  The problem is this protocol meaning is proprietary and by
definition non-interoperable.  Moreover, the draft presents no
negotiation mechanism, nor do I see how there could possibly be a
negotiation mechanism.
Standard SIP user agents and proxies will not be able to negotiate
common communication parameters if a key protocol element is
proprietary.

Moreover, use of the P-Preferred-Service in this manner will encourage
proxies and user agents to not bother to parse and interpret the
existing information contained in the SIP INVITE.  At this point, the
protocol is no longer SIP.

To reiterate, I have no problem with the publication of
P-Asserted-Service, as defined in the above named draft, as an
IETF-reviewed publication.

However, I would strongly object to the publication of
P-Preferred-Service as an IETF reviewed publication.  It presents a
clear and present danger to the Internet, and could potentially end the
possibility of having interoperable communications in the Internet."


There was a subsequent discussion on this which seems primarily to be
clarification of intent (this is recorded in the comments summary but I
do not reproduce it here.

As a result of this comment, I added the following text (but did not
remove the header) in the new version:

-	Added the following text to the introduction: " This document
also makes use of the terms "derived service identification" and
"declarative service identification" as defined in
draft-ietf-sipping-service-identification <xref
target="I-D.draft-ietf-sipping-service-identification" />.

-	And the following text to the definition of P-Asserted-Service:
" The P-Asserted-Service header field carries information that is
derived service identification. While a declarative service
identification can assist in deriving the value transferred in this
header, this should be in the form of streamlining the correct derived
service identification."

-	And the following text to the definition of P-Preferred-Service:
" The P-Preferred-Service header field carries information that is
declarative service identification. Such information should only be used
to assist in deriving a derived service identification at the recipient
entity.


Since the publication of the -02 version, John Elwell has weighed in
with the following comment:

[JRE] The document is certainly inconsistent. In section 1 it states:
"The use of these extensions is only applicable inside an
   administrative domain with previously agreed-upon policies for
   generation, transport and usage of such information."
and then in "In addition, this extension
   allows user agent clients outside the trust domain to provide a hint
   of the requested service."
which, assuming trust domain in this sentence equates to administrative
domain in the first quoted sentence, appears to be in contradiction. All
the stuff do to with P-Preferred-Service seems to be in contradication
to the first quoted sentence.

Then in section 2 it states "The use of these extensions is
   only applicable inside a 'Trust Domain' as defined in Short term
   requirements for Network Asserted Identity (see RFC 3324 [RFC3324])."
which again seems to be contradicated by the P-Preferred-Service parts.

Also the motivation for P-Preferred-Service seems rather weak. How can
it "assist", if the service is derivable from other information in the
request?

It seems to me that P-Preferred-Service does not add any value and
contradicts certain statements in the draft.


My response at the moment:

The header is currently required by 3GPP. Different people in 3GPP put
different slants on the header, but at least in the manner it is used in
the network, it is used to make the service analysis more efficient,
i.e. it can be used to seed the analysis such that the network checks
whether it can be this service before examining all the other
possibilities.

The current 3GPP text runs as follows for the network proxy:

"4B) if the request contains a P-Preferred-Service header field, check
whether the ICSI value contained in the P-Preferred-Service header field
is part of the set of the subscribed services for the served user and
determine whether the contents of the request (e.g. SDP media
capabilities, Content-Type header field) match the ICSI for the
subscribed service:
a)	if not, as an operator option, the S-CSCF may reject the request
by generating a 403 (Forbidden) response. Otherwise remove the
P-Preferred-Service header field and continue with the rest of the
steps; and
b)	if so, then include a P-Asserted-Service header field in the
request containing the ICSI value contained in the P-Preferred-Service
header field, remove the P-Preferred-Service header field, and continue
the procedure with step 5;

4C)	if the request does not contain a P-Preferred-Service header
field, check whether the contents of the request match a subscribed
service for each and any of the subscribed services for the served user:
a)	if not, as an operator option, the S-CSCF may reject the request
by generating a 403 (Forbidden) response; and
b)	if so, and if the request is related to an IMS communication
service and the IMS communication service requires the use of an ICSI
value then select an ICSI value for the related IMS communication
service and include a P-Asserted-Service header field in the request
containing the selected ICSI value; and
c)	if so, and if the request is related to an IMS communication
service and the IMS communication service does not require the use of an
ICSI value then continue without including an ICSI value; and
d)	if so, and if the request does not relate to an IMS
communication service (or if the S-CSCF is unable to unambiguously
determine the service being requested but decides to allow the session
to continue) then continue without inclding an ICSI value;"


Comments and views please.


Regards

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