I would propose to make sure that the policy framework allows an extension like the one proposed to be added in the future. This will allow a way forward without putting a header parameter in right now.
Thanks, Volker Andrew Allen wrote: > 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
