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