Subject: [dispatch] XML questions about draft-ietf-sipping-media-policy-dataset-08

From: "Dale Worley" <[email-masked]>
Date: Wed, 09 Dec 2009 16:14:45 -0500

I've edited my questions about the XML in
draft-ietf-sipping-media-policy-dataset-08 into better order.  They are
appended to this message.

Dale
-----------------------------------------------------------------------------
This is based on a copy of the
draft-ietf-sipping-media-policy-dataset-08 draft, which I have in a
private directory.  Apparently, the -08 version was never published.
I assume that the authors have an archival copy of -08.  The MD5 of my
copy of the text version of -08 (with LF as EOL) is
dfd01da655ee324727a0f0fbe6ff69a8.

- Section 1

Are merging rules still needed?  We are no longer using
session-policy-dataset, which required merging, but IIRC someone
mentioned an additional need for merging.

- Section 4.2

Section 4.2 contains:

   If a UA has an SDP offer as well as an answer [RFC3264] and wants to
   create a session info document, the UA MUST use the answer to fill in
   the elements of the session info document except for the remote-host-
   port and local-host-port elements, which are taken from the remote
   and local session description respectively.  The local session
   description is the one created locally by the UA (i.e., the offer if
   the UA has initiated the offer/answer exchange).  The remote session
   description is the one received from the remote UA.

   If a UA has an SDP offer as well as an answer [RFC3264] and wants to
   create a session info document, the UA MUST use the answer to fill in
   the elements of the session info document except for the local-host-port
   and remote-host-port elements, which are taken from the SDP generated
   by the UA and the SDP received by the UA, respectively (regardless of
   which is the offer and which is the answer).

However, this process doesn't seem to allow for the possibility that
the locally-provided and remote-provided SDP may differ.  (Although I
think the relevant differences are restricted to which codecs may be
used.)  It seems that directionality attributes could/should be used
to have the media-policy specify the admitted codecs in each direction
appropriately.

The specification of codecs in SDP is strange in that an answer may
contain codecs that are not given in the offer, but they are not
usable in the session.  How should they be encoded in session-info?

Section 4.2 seems to envision that an offer SDP can be mapped into a
media-policy, which can then be restricted or subsetted to give a new
media-policy, which can then be translated into an answer SDP.  But
the transformation of SDP into media-policy XML seems to lose the
sequencing of the m= lines, in that there is no semantics specified
for the <stream> elements of a media-policy.  Perhaps the intention is
that the <stream> elements correspond in order to the m= lines, but
that does not seem to be stated.

Note that SDP can contain zero m= lines, which would seem to map to a
<session-info> with a <streams> with no <stream>.  But that is not
allowed by 6.3.

- Section 5

Perhaps this change of wording would be clearer:

   Session policy documents describe a policy for SIP sessions.  Session
   policy documents are independent of >>any<< specific session description
   and express general policies for SIP sessions.

- Section 5.1

The <property_set> element is not being used any more.

- Section 6.2

Section 6.2 says that at least one codec must be allowed per media
type (see second sentence), but the correspondence between codec and
media type isn't explicit, and it would be a difficult validity
constraint to verify.  Also, the text does not specify that we're only
concerned with media types that are admitted by the <media-types>
element.  And worse, what if the <media-types> are a set-complement
construction (excluded-policy="allow"), in which case the set of
admitted media-types is not knowable?  I would suggest removing the
restriction, and understanding that an allowed media-type with no
allowable codecs is unusable in practice.

- Section 6.2.1.1

The <codec> and <mime-type> elements want to specify the codec via a
mime-type, but that isn't what SDP uses.  The translation between the
two is described in RFC 4855 section 3, which should be referenced.

- Section 6.3.1

How are 0 port values encoded?  Semantically, it identifies a
"sendonly" mode.  Should it be encoded as a zero value of
<remote-host-port> or (better) by appropriate direction attributes.
In any case, this should be specified clearly to avoid interoperation
problems.

- Section 6.4

Section 6.4 uses the phrase "sessions a UA may set up in parallel".
Does this refer to the set of sessions for a single dialog?  Or the
set of all sessions of all dialogs that the UA is participating in at
one time?

- Section 6.10

Do we want <context> to be subordinate to <session-info>?  This is
arguably a layer violation:  <context> and <session-info> could be
siblings under an element that declares that the policy applies to the
context.  This allows <session-info> to have defined semantics, but
allowing its containing element/message to determine what those
semantics apply to.

- Section 8

The TBD note at the beginning of section 8 (and the task it described)
can be removed now that sipping-profile-datasets has been abandoned.

Where is the up-to-date version of "uaprofile.rng"?  What is the
proper URL to access it?

- Imported from ietf-sipping-profile-datasets

The 'policy' and 'excluded-policy' attributes are quite grotty, as
they can be used only in specific combinations among several related
elements, and are quite verbose in any case.  It would be much better
to define a "set" construct (to specify a finite set of permitted
values) and a "set-complement" construct (to specify all values are
permitted except a finite set of values).  These constructs have the
same expressive power as the existing attributes.  E.g.:

      <media-types excluded-policy="disallow">
        <media-type policy="allow">audio</media-type>
        <media-type policy="allow">video</media-type>
      </media-types>
      <codecs excluded-policy="allow">
        <codec policy="disallow">
          <mime-type>audio/G729</mime-type>
        </codec>
        <codec policy="disallow">
          <mime-type>audio/G723</mime-type>
        </codec>
      </codecs>

becomes

      <media-types>
        <set>
	  <media-type>audio</media-type>
	  <media-type>video</media-type>
	</set>
      </media-types>
      <codecs>
        <set-complement>
	  <codec>
	    <mime-type>audio/G729</mime-type>
	  </codec>
	  <codec>
	    <mime-type>audio/G723</mime-type>
	  </codec>
        </set-complement>
      </codecs>

but correct usage of this form is much easier to describe in the schema.

(Looking at the example, perhaps we want to replace the <set> and
<set-complement> elements with "set" and "set-complement" attributes
on its parent element.  That is less mathematically pure, but has the
same expressive power and is more terse.)

As far as I can tell, there are nine "container" types which use the
set/complement mechanism:

    6.1 <media-types> container of <media-type>
    6.2 <codecs>
    6.3 <streams>
    6.4 <max-bw>
    6.5 <max-session-bw>
    6.6 <max-stream-bw>
    6.7 <media-intermediaries>
    6.8 <qos-dscp>
    6.9 <local-ports>

The "direction" attribute seems to be weakly defined.  As far as I can
tell, in a policy one can have, for any of the nine container types,
(1) no element, (2) one element with the value "sendrecv", or (3)
optionally one element with the value "sendonly" and optionally one
element with the value "recvonly".  But this is not stated in either
this draft or draft-petrie-sipping-profile-datasets and I might well
be wrong.

Also, if we still utilize merging, we need to state that case (2) is
equivalent to duplicating the value, with one copy marked "sendonly"
and one marked "recvonly", so that we have explicitly shown how to
align two containers with direction attributes in order to merge
(intersect) them.

- Empty elements

There are a lot of situations where it is sensible for an element to
have zero sub-elements, in that the stated rules give a clear meaning
to the element.  In particular, any "set" construct with zero elements
permits nothing, and any "set-complement" construct with zero elements
permits everything.  But most of the relevant elements (including all
the container types) are defined to require at least one sub-element.

However, there is currently a special case in section 4: It states
that an empty <session-info> rejects a session.  (If it wasn't for the
defined special case, a session with *no* streams would be admissible
under this policy.)  It would be better if the "reject everything"
state could be described in a different manner, so as to avoid the
special case.

- The word "container"

Beware of the use of the word "container".  In the
session-policy-dataset, "container" is (mostly) used to describe
elements which inherit from <setting_container>.  I suggest that we
restrict the use in media-policy-dataset in that way.

Although now that we are removing session-policy-dataset, "container"
is no longer defined by <setting_container>, but it still means the
elements which carry "direction", "policy", etc.

That change would require rewriting these paragraphs of 6.1:

   The <media-types> element can only be used in session policy document
   (i.e., inside the <session-policy> >>element<<).

   This element MAY have the following attributes (see Section 3.3):
   direction, visibility, excluded-policy.

   Multiple <media-types> elements MAY only be present in a <session-policy>
   element if each applies to a different set of streams (i.e., one
   <media-types> element for incoming and one for outgoing streams).
   The <media-types> element MUST contain one or more <media-type>
   elements.

There may be other uses of "container" that should be changed.

- "Registered" requirements

In a number of places, parameters are required to have values that are
appropriately registered.  On the face of it, this prevents
experimental or private-use values from being used at all.  This is
probably not what we intend.  Given that there is general knowledge of
how to create private-use values, these registration requirements
should just be deleted.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 17 Dec 2009 18:00:31 +0200

Hi Volker,

could you please submit 08 per Dale's email below so that people on this 
list can follow the discussions? Right now, the last revision that was 
submitted is 07:

http://tools.ietf.org/html/draft-ietf-sipping-media-policy-dataset-07

Thanks,

Gonzalo