Re: [Sipping] [RAI] draft-ietf-sipping-media-policy-dataset: The implied boolean logic of policy operations

[Gonzalo Camarillo <[e-mail]>]

Hi Dale,

here you have my answers not only to your original email, but to the
whole section on open revision items you added to the draft.

> 1.1. Media Types
> 
> 
> 1.1.1. Require Registration
> 
> 
>    In -10, all media type names that are mentioned in a MPDF are
>    explicitly required to be IANA-registered.  Technically, this means
>    that experimental or private-use types can not be used, even in
>    situations where all participants are aware of non-registered media
>    types.  In practice, people will go ahead and use them anyway.  I am
>    proposing to remove the "registered" requirement.

yes, I agree this draft does not need to put unnecessarily restrictive
requirements on the tokens to be placed in MPDF documents.

> 1.1.2. Terminology
> 
>    In a number of places, media types are called "MIME types".  The
>    latter is common usage, but it is not official, and as RFC 4288 makes
>    clear, media types are independent of their use within MIME.  I've
>    fixed the wording of the draft in a number of places to correct this.

Perfect.

> 1.1.3. Rename the <mime-type> child of <codec>
> 
>    There is an element <mime-type> that is a child of the <codec>
>    element that carries a media type and subtype.  The natural fix would
>    be to change this to <media-type>, but there is already an element of
>    that name that is a child of <stream> that carries a media type
>    (without subtype).  I would like a name that means "media type and
>    subtype", but I can't think of a short one.  Suggestions?

I do not think we should spend too much time thinking of a good name for
it. Let's just call it <media-type-subtype>, for instance.

> 
> 1.2. Remove reference to uaprofile.rng
> 
>    The Relax NG schema given in draft-ietf-sipping-media-policy-dataset
>    includes "uaprofile.rng".  As far as I can figure out, uaprofile.rng
>    is the schema defined in draft-ietf-sipping-profile-datasets, which
>    has been abandoned.  So we need to remove the reference to
>    uaprofile.rng.  It's possible that there are things defined in that
>    schema that need to be either deleted from
>    draft-ietf-sipping-media-policy-dataset, or copied from the abandoned
>    draft into the schema in draft-ietf-sipping-media-policy-dataset.
> 
>    If anyone has further information about this, please tell me.
> 

Yes, although a cleanup was performed in order to get rid of the
now-abandoned draft, we may still need to finish it properly.


> 1.3. Remove <property-set>
> 
>    I have updated the text of draft-ietf-sipping-media-policy-dataset-11
>    to consistently use "property-set" rather than sometimes using
>    "property_set".  However, it seems to me that the <property-set>
>    element serves no use (now that sipping-profile-datasets has been
>    abandoned).  The draft says that each <session-info> and <session-
>    policy> appears in a <property-set>, and <property-set> can contain
>    more than one of each.  But there seems to be no practical use for
>    this grouping; the semantics of <session-info> and <session-policy>
>    is completely standalone.
> 
>    So I am proposing eliminating the <property-set> element entirely,
>    making <session-info> and <session-policy> into top-level elements.

Yes, this is part of the cleanup we referred to above.

> 1.4. Specifying Sets
> 
>    There are many properties for which the values are sets of primitive
>    values.  The current syntax for specifying sets is awkward.  In
>    addition, it is not permitted to specify a set containing zero
>    elements.  Sessions containing empty sets are not useful to write,
>    but it is easy to generate them when applying a policy to a <session-
>    info>.  So the syntax for set values needs to be updated.

Yes, it makes sense.

> 1.5. Specifying Bandwidth Limitations
>
>    Looking at the XML of draft-ietf-sipping-media-policy-dataset, I see
>    this paragraph:
> 
>   <!--
>         <t>If a b= line is present for a media stream, this line MUST be
>         used to create the bandwidth elements.</t>
>   -->
> 
>    SDP provides "b=" lines for specifying bandwidth limitations.
>    Similarly, MPD provides <max-bw>, <max-session-bw>, and
>    <max-stream-bw> elements, and the draft states that they are
>    equivalent to various forms of the b= line.  Should we require that
>    when SDP is translated into MPD that the bandwidth limitations be
>    translated?

Yes, it makes sense.

> 
> 1.6. Rejecting a media stream
> 
>    In draft-ietf-sipping-media-policy-dataset-10 there is no explicit
>    way to indicate that a stream has been rejected (which is needed to
>    correspond to an m= line in SDP where the port number is 0).
>    Implicitly, this can be done by setting the port number in the
>    <local-host-port> or <remote-host-port> to 0.  But that is pretty
>    ugly.  I propose that we introduce an attribute of the <stream>
>    element to indicate that a stream has been rejected/disabled:
> 
>        <stream enabled="no">
> 
>    The default value of "enabled" would be "yes".
> 
>    This resolves the problem of how a policy server would modify a
>    <session-info> to make it conform to a policy if one of the <stream>s
>    contradicted the policy: The policy server would put enabled="no"
>    onto the <stream>.
> 
>    For consistency, a policy server could effectively reject a proposed
>    session by rejecting all of the streams within it.  This would be
>    slightly different than rejecting the session as a whole by returning
>    an empty session-info document, <session-info/>.  This distinction
>    corresponds to the difference between an SDP offer/answer negotiation
>    failing, and the negotiation succeeding but the answer rejecting all
>    the m= lines in the SDP.

Yes, it makes sense.

> 
> 1.7. 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:
>    o  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.).

Yes.

>    o  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.

Yes.

>    o  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.

When policies apply to different aspects (e.g., video codecs and audio
codecs), this is true. However, if different policies apply to the same
aspect, they need to be merged. And when merging the policies, the
resulting stream needs to be compliant to all policies (i.e., an AND
operation). For example, if one policy allows codecs 0 and 8 and another
only allows 8, the resulting policy is to only use codec 8. If a policy
allows only codec 0 and another policy only allows codec 8, the result
is a null session. I am not sure if this is what you are saying above
(and below in the rest of the section), though.

Thanks,

Gonzalo

>    o  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.
>    o  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>.
>    o  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.)
>    o  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*.