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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf