A User Agent Profile Data Set for Media Policy
Note: This ballot was opened for revision 02 and is now closed.
(Robert Sparks) Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Benoît Claise) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) (was Discuss) No Objection
(Brian Haberman) No Objection
(Russ Housley) No Objection
Barry Leiba (was Discuss) No Objection
Comment (2012-09-17 for -03)
All DISCUSSes and substantive comments were taken care of in version -03; thanks. ======== Other comments; no need to respond to these. Really, I'm just grumbling. I have to grumble about the shepherd writeup for this: The document, in particular the registration of the media type/subtype media-policy-dataset+xml, has been reviewed on the ietf-types mailing list. It has not "been reviewed" there at all. A request for review was posted, and there were no responses. That's not a bad thing, but it should have been explained that way, not presented as a review. I also have to grumble about the IANA Considerations section, which does not clearly specify what registries it's asking for things to be put into. IANA figured it out, so I'm not asking for any changes here. Just for future: please be clear about this, so IANA never has to guess (and will not, therefore, ever guess wrong).
(Pete Resnick) No Objection
Comment (2012-07-18 for -02)
Section 4.3.1: The <stream> element MUST contain one <media-type> element, one or more <codec> elements and one <local-host-port> element. The <stream> element MAY contain one <remote-host-port> element. That last MAY strikes me as ambiguous. Did you mean MUST contain zero or one <remote-host-port> elements? Section 4.4: Multiple <media-intermediaries> elements MAY only be present in a container if each applies to a different set of streams (e.g., one <media-intermediaries> element for incoming and one for outgoing streams). Another ambiguous MAY. Instead can I suggest: Multiple <media-intermediaries> elements MUST NOT be present in a container unless each applies to a different set of streams (e.g., one <media-intermediaries> element for incoming and one for outgoing streams). See also 5.3, 5.4, 5.6. "MAY only" is a bad construct. Section 6.7.5: The use of this token is described in the Framework for SIP Session Policies [I-D.ietf-sip-session-policy-framework]. Since the token value must be encodable as a SIP URI parameter value, it MUST consist of ASCII characters, that is, in the range U+0020 to U+007E. Either strike ", that is, ", or change "ASCII characters" to "visible ASCII characters plus space". And you do want to allow space? And not TAB? And not other things that can be %encoded? I'm not clear on the requirement here. For the record, "token" is not defined this way in 3261. Just looking for clarification.
(Martin Stiemerling) No Objection
(Sean Turner) (was Discuss) No Objection
Comment (2012-07-19 for -03)
s3.3: Says the recipient MUST ignore the attribute. Is the recipient the user agent or the user? I suspect it's the former - shouldn't it say that instead? s3.3.1: Is there an override on this? I'm thinking I'm with Stephen here. An additional reason is that normally display stuff (my technical term) is out-of-scope - isn't it? s4.2: optional is redundant: r/MAY contain the optional/MAY contain the