draft-ietf-sipping-media-policy-dataset: The implied boolean logic of policy operations

I am starting work on a messy part of the media policy dataset
definition:  Specifying the logic when a policy is applied to a
session-info, and also specifying how two policies are combined to
apply jointly to session-infos.  The goal is to implement one's
intuitive expectations while introducing as few special cases as
possible.

My current analysis is:

- The primary operation is applying a session-policy to a session-info
  to produce a possibly more restricted session-info.  This is done by
  applying the session-policy to each stream in turn, which may
  "restrict" the stream (in regard to bandwidth, codecs, etc.).

- A stream may be restricted to the point that it permits no media
  whatsoever.  Such "null" streams are all logically equivalent,
  although a null stream can be represented in many different ways.
  When translated back into SDP, a null stream becomes a rejected
  m= line.

- The different <stream> elements in a session-policy are effectively
  ORed together, in that the policy intends to permit any stream that
  conforms to *any one* of the <stream> elements.  This is necessary
  because e.g. a session-policy can contain one <stream> that specifies
  audio media and restricts the codecs permitted for audio, and
  another <stream> that specifies video media and restricts the codecs
  permitted for video.

- Thus, applying a session-policy to a stream involves applying each
  session-policy <stream> to the stream, and then choosing the "best"
  result.  In practice, we expect that the streams admitted by the
  session-policy <stream> elements to be disjoint (e.g., one is for
  audio, one is for video), so the result of applying any but one
  <stream> will be a null stream, and the "best" result will be the
  only non-null result.

- The alternative strategy of "unioning" the results of applying each
  <stream> element cannot be used because it can allow the resulting
  session to exceed all of the <stream> element policies.  Consider
  the policy

      <streams>
        <stream> codecs: audio/foo, bandwidth: 10 </stream>
        <stream> codecs: audio/foo,audio/bar, bandwidth: 1 </stream>
      </streams>

  applied to the requested stream "codecs: audio/foo,audio/bar,
  bandwidth: 10".  The result of restricting with the first <stream>
  is "codecs: audio/foo, bandwidth: 10" and the result of restricting
  with the second <stream> is "codecs: audio/foo,audio/bar, bandwidth:
  1".  The union of the two (the "smallest" stream that contains them
  both) is "codecs: audio/foo,audio/bar, bandwidth: 10", which is not
  allowed by either <stream>.

- Within this context, combining two policies to form a joint policy
  that enforces both their restrictions simultaneously is simple:  The
  resulting policy is made by "intersecting" all possible pairs of
  <stream>s, one from the first policy and one from the second policy.
  (Intersections that result in null policies can be dropped from the
  result.)

- I haven't studied the role of the directional attributes yet, but
  currently I believe that a bidirectional session-info <stream> can
  be treated as an abbreviation for two session-info <stream>s, one in
  each direction, and a bidirectional session-policy <stream> can be
  treated similarly.  Or, directionality can be treated as an
  attribute with two possible values, *with identical results*.

Comments?

Dale
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP