Firstly I apologize for the very late comments on this draft which has already completed WGLC. I recently reviewed draft-ietf-sip-session-policy-framework-02 with a view to its utilization in 3GPP IMS particularly with regard to its application in mobile networks. After reading the draft I have some concern that the Subscribe/Notify mechanism for the Policy channel is too heavy for use in Cellular and other narrow band networks. The session establishment times for cellular using SIP are already too long. Adding an additional SUBSCRIBE, 200 OK, NOTIFY, 200 OK per UA to that to go fetch the local session-specific policy will not be acceptable. It seems there could be other more efficient means available in certain networks to obtain the session-specific Policy. While the Subscribe/Notify mechanism may be the best general purpose mechanism it seems to me that the mechanism ought to be extensible to allow additional Policy channel mechanisms to be defined in the future which probably means extensibility to support URIs other than just SIP/SIPS URIs in the Policy-Contact header. The draft anticipates that non SIP means might be used to obtain the session-independent policies so why not also anticipate the possibility that non SIP means might in the future be used to obtain session-specific policies? I have had some discussion with Volker already on this issue and it seems it would be possible to modify the Policy-Contact header to optionally allow multiple URIs of different types for the same Policy Document from the same domain with inclusion of a SIP or SIPS URI being mandatory. e.g Policy-Contact: sip:[EMAIL PROTECTED]; sips:[EMAIL PROTECTED]; http:[EMAIL PROTECTED]; https:[EMAIL PROTECTED] <https://[EMAIL PROTECTED]> , sip:[EMAIL PROTECTED]; sips:[EMAIL PROTECTED]; http:[EMAIL PROTECTED]; https:[EMAIL PROTECTED] <https://[EMAIL PROTECTED]> Support of SIP or SIPS URI schemes and the Subscribe/Notify mechanism for the Policy Channel would continue to be mandatory for interoperability but the possibility to include additional URI schemes for obtaining the session-specific policy document would be added. This seems like a relatively straight forward change to make even though it is a very late proposal. Since one of the original primary drivers for the session policy work originated from 3GPP requirements it would be a shame if the solution wasn't sufficiently extensible to allow 3GPP in the future to use it. Andrew Allen Manager Standards Research In Motion Ltd Office +1 847-793-0861 x20824 BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ <http://www.rim.com/> --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
