Subject: Re: Last Call: draft-drage-sipping-service-identification (A Session Initiation Protocol (SIP) Extension for the Identification of Services) to Informational RFC

From: Eric Burger <[email-masked]>
Date: Wed, 01 Aug 2007 15:26:52 -0400

A better title for this e-mail is, "P-Preferred-Service Considered Harmful."

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.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Atle Monrad (GR/ETO)" <[email-masked]>
Date: Fri, 3 Aug 2007 14:55:52 +0200

All

Due to lack of response, and as my 1st mail had a different Subject-line
thus may have been missed by mistake, I resubmit the comments. Sorry for
any inconvenience.

-------

On draft-drage-sipping-service-identification-01 I would like to ask
wheter it would be more beneficial to leave out the URN-namespace
registration and only point to e.g. RFC 2141.

This would make the draft focusing on the usage of the P-headers, which
I think is fine. The draft would also be flexible and could be used by
other organisations that has their own URN-administration. E.g. OMA
which describes their internal URN-structure in RFC 4358. 3GPP is in the
process of creating a similar draft that can be found as
draft-monrad-sipping-3gpp-urn-namespace.  

As the draft-drage-sipping-service-identification-01 currently desribes
the top-level URN for 3GPP ("3gpp-service" and "3gpp-application"),
URN-administration is as I see it needed anyway for the subservice
identifiers and the application identifiers within 3GPP. Further, OMA
will as I understand it need to either update Keiths draft or write an
OMA-specific draft to include the possible "OMA-service" and
"OMA-application" top level URNs. I do not understand the benefit with
having the top-level URNs handled by IANA as IANA anyway subcontract the
URN administration to other SDOs.

By leaving the URN-administration out,
draft-drage-sipping-service-identification would gain flexibility to be
used by other organisations as OMA without any additions. As the draft
mention POC as a "service" in an example, I would also find it useful
that the draft is flexible enough to also cover OMA.

My comments mainly concerns the introduction and the clauses 4.3, 4.4
and 8, and can be taken into account without much rewording and does not
affect the technical content concerning the definition and usage of
P-Preferred-Service and P-Asserted-Service.

I fully understand and support the need to expedite the handling of this
draft due to 3GPP, but I do not think that this comment will slow down
this process, but rather secure that the draft can be completed timely
with the needed flexibility. 

Thanks

Atle Monrad
Chairman 3GPP CT1

-----Original Message-----

The IESG has received a request from an individual submitter to consider
the following document:

- 'A Session Initiation Protocol (SIP) Extension for the Identification 
   of Services '
   <draft-drage-sipping-service-identification-00.txt> as an
Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf at ietf.org mailing lists by 2007-08-06. Exceptionally, 
comments may be sent to iesg at ietf.org instead. In either case, please

retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-drage-sipping-service-identifi
cation-00.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
15991&rfc_flag=0

_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce