I propose we go with the alternative that enables a domain to insert URIs with additional protocol schemes into the policy contact header (e.g. HTTP) in addition to SIP.
A negotiation mechanism could always be added later if it was determined to be needed as an optiomization but is not needed now for sure. The important thing is to have some flexibility for future additional protocols on the Policy Channel. -----Original Message----- From: Volker Hilt [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2008 4:05 PM To: [email protected] Cc: Andrew Allen Subject: Re: [Sip] draft-ietf-sip-session-policy-framework-02 The main request here is to allow different protocols on the policy channel, in addition to the SUB/NOT mechanism defined in the policy package. The discovery mechanism for policy servers defined in the framework draft would still be used but it would be possible to use other protocols for retrieving policies (e.g., HTTP). This would require that UAs and proxies can come up with policy channel protocol both support. A full blow negotiation mechanism seems overkill and is also difficult to do on the UAS side. The reason is that the UAS will receive a request that already contains the policy server URI and, thus, it is too late to negotiate a format for it. An alternative could be to enable a domain to insert URIs with additional protocol schemes into the policy contact header (e.g. HTTP) in addition to SIP. Yet another alternative is, of course, to keep things as they are and only allow the policy package for the policy channel. Thanks, Volker Andrew Allen wrote: > 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/ > > > > --------------------------------------------------------------------- > 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 --------------------------------------------------------------------- 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
