I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-camarillo-rai-media-policy-dataset-01
Title: A User Agent Profile Data Set for Media Policy
Reviewer: Henry S. Thompson
Review Date: 31 May 2012
IETF Last Call Date: 2012-06-11

Summary: This draft is almost ready for publication as a Proposed
         Standard but has a few issues that should be fixed
         before publication

Major Issues: 

1 A bit more context is needed, given that section 3 dives right in to
defining attributes.  We need to know Why this XML format
is _needed_ -- why aren't session definitions (per RFC4566)
sufficient?  Just a brief explanation of motivation should do the job.

5.3/4/5/6 "Multiple <media-types-allowed> elements MAY only be present
in a container element if each applies to a different set of streams
(e.g., one <media-types-allowed> element for incoming and one for
outgoing streams)." -- How is this possible?  The only 'container
element' allowed by the schema is <session-policy>.  How does an
application know _which_ stream is meant to be constrained by _which_
allowed set???  Simlarly for all the other allowed/excluded elts, and
various max/min settings if they appear under <session-policy> rather
than <session>.

6.5 max-stream-bw: It's not clear if it's an error == "MUST ignore" if
the media-type attribute and the label attribute conflict, i.e. the
stream picked out by the label isn't for the named media.  In a
similar vein, it's not clear to what extent merging is restricted to
pairs whose label and/or media match. . .

Similar issues arise for <qos-dscp>.

Minor Issues: 

3.1 It's a bit odd to reference XML 3rd edition -- XML 5e [1] has been
available for over 3 years now. . .

3.3.4 'media-type' attribute -- Are more specific values than those
listed allowed?  Probably the most common understanding of the phrase
'media type' is exemplified by text/plain, image/svg or
application/xml -- if these are _not_ allowed, say so.  If they are,
include one or two in the "such as" list.

4.1 Wrt codecs, the two MUST statements wrt description
vs. offer/answer are superficially contradictory.  This para. needs to
be split into two sub-cases, so the processing for single
descr. vs. pair of descrs is clear.

4.1 It would be nice to see two generic templates demonstrating the
mapping rules for the one- and two-description cases, i.e. something
along the lines of

   c=IN IP4 h                       <session-info>
   m=m1 p1 RTP/AVP c11 c12 . . .      <streams>
   a=label:l1                           <stream label="l1">
   a=rtpmap:c11 t11		          <media-type>m1</media-type>
   a=rtpmap:c12 t12		          <codec q="0.9">
   a=rtpmap:. . .		           <media-type-subtype>t11</media-type-subtype>
   m=m2 p2 RTP/AVP c21 c22 . . .          </codec>
   a=label:l2			          <codec q="0.8">
   a=rtpmap:c21 t21		           <media-type-subtype>t12</media-type-subtype>
   a=rtpmap:c22 t22		          </codec>
   a=rtpmap:. . .		          . . .
   . . .			          <local-host-port>h:p1</local-host-port>
				        </stream>
				        <stream label="l2">
				          <media-type>m2</media-type>
				          <codec q="0.9">
				           <media-type-subtype>t21</media-type-subtype>
				          </codec>
				          <codec q="0.8">
				           <media-type-subtype>t22</media-type-subtype>
				          </codec>
				          . . .
				          <local-host-port>h:p2</local-host-port>
				        </stream>
				        . . .
				      </streams>
                                    </session-info>

and similarly for the two-input case.

4.1 The fact that the specified mapping is lossy in both directions
should be called out, e.g. v= and t= lines are lost in one direction,
and <context> is lost in the other.

5.1 Wouldn't this be better at the _end_ of section 5, once the
elements to be merged have been introduced?

5.1.2

    The two </codecs> end tags should be
    </codecs-excluded> and </codecs-allowed> respectively.

7.1 The <session-policy> element needs
          xmlns="urn:ietf:params:xml:ns:mediadataset"

    The end tags </media-types> and </codecs> should be
    </media-types-allowed> and </codecs-excluded> respectively.

7.2 Both <session-info> elements need
          xmlns="urn:ietf:params:xml:ns:mediadataset"

    All the <codec> elements need 'q' attributes according to the
    text.  The schema does not require this.  Shouldn't it do so?

8 Schema

ElementInfoContext is undefined.  I presume something along the lines
of 

           <define name="ContextModel">
             <interleave>
                   <optional>
                     <element name="info">
                       <data type="string" />
                     </element>
                   </optional>
                    <optional>
                    <element name="policy-server-URI">
                       <data type="string" />
                     </element>
                   </optional>
                    <optional>
                    <element name="token">
                       <data type="token" />
                     </element>
                   </optional>
                    <zeroOrMore>
                     <element name="contact">
                        <data type="string" />
                     </element>
                   </zeroOrMore>
             </interleave>
           </define>

           <define name="ElementContext">
               <element name="context">
                   <interleave>
                    <ref name="ContextModel"/>
                   </interleave>
               </element>
           </define>

           <define name="ElementInfoContext">
            <element name="context">
             <interleave>
              <ref name="ContextModel"/>
              <optional>
		<element name="request-URI">
		  <data type="string" />
		</element>
	       </optional>
             </interleave>
            </element>
           </define>

is what you meant, if I read the text correctly.

With the above fixes to schema and instances, the examples are all valid.

Nits:

3.1 "namespace URIs for schemas" --> "namespace URIs for elements", I
would prefer. . .

4 "<session-info><\session-info>" --> "<session-info></session-info>"

5.1.2 "encoding of profile of the codec" --> "encoding or profile of
                                              the codec"
      [I guess. . .]
 -----------
      "Other encoding or profiles of the same codec are unaffected." -->
      "Other encodings or profiles of the same codec are unaffected."
 -----------
      "apply all containers it has received one after the other the
       set of media- types/codecs it supports." -->

      "apply all containers it has received one after the other to the
       set of media- types/codecs it supports."

      [I guess. . .]

ht

[1] http://www.w3.org/TR/2008/REC-xml-20081126/
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]