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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]