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

From: Volker Hilt <[email-masked]>
Date: Fri, 15 Jan 2010 10:02:10 -0500

Gonzalo, All,

the -08 version is now available at:

http://www.ietf.org/id/draft-ietf-sipping-media-policy-dataset-08.txt

Thanks,

Volker

Gonzalo Camarillo wrote:
> 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
> 
> Dale Worley wrote:
>> 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: "Elwell, John" <[email-masked]>
Date: Mon, 18 Jan 2010 14:17:54 +0100

This normatively references draft-ietf-sipping-profile-datasets. What is the status of that draft - is it still being pursued?

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Volker Hilt
> Sent: 15 January 2010 15:02
> To: Gonzalo Camarillo
> Cc: DISPATCH
> Subject: Re: [dispatch] XML questions about 
> draft-ietf-sipping-media-policy-dataset-08
> 
> Gonzalo, All,
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Volker Hilt <[email-masked]>
Date: Mon, 18 Jan 2010 08:54:22 -0500

John,

no, it is not. We're preparing a new version that will remove this
reference.

Thanks,

Volker