From: Worley, Dale R (Dale) Sent: Thursday, May 12, 2011 5:56 PM To: Gonzalo Camarillo Subject: RE: Progressing draft-ietf-sipping-media-policy-dataset I just ran into something I had overlooked. I've been taking the Abstract seriously when it says "It can be used to describe the properties of a specific SIP session or to define policies that are then applied to different SIP sessions." That is, I've assumed that a session-policy is sort of a generic session-info whose <stream>s show what sorts of <stream>s are permitted in a conforming session-info. This is what lead to the "implicit Boolean logic" message. But when I look at the examples, I see that session-policy and session-info documents have completely different structure. The session-policy is a collection of elements, each of which specifies a particular restriction on conforming session-info's. And in particular, a session-policy does not contain stream elements. A certain amount of my editing has been driven by this misconception, although I don't think it would take much work to reverse those edits. The high-level question is whether we want to stay with the original scheme, where session-policy's have a distinctly different structure, or whether we want to go with my misconception, where session-policy are template session-info documents. The original scheme would be easier for people to understand and thus to implement, but it has the limitation that one has to specifically define an element to represent every restriction that anyone will want to use. The "new" scheme requires more abstract thought, but it automatically provides ways to make restrictions in every feature that can be expressed in a session-info, and so extensions of the data set require less design, and the processing code can be written in a more generic way. What do you think? Dale _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
