A Mixer Control Package for the Media Control Channel Framework
draft-ietf-mediactrl-mixer-control-package-14

[Ballot discuss]
Thank you for the updated -13. I really appreciate the effort.

I am sorry for nitpicking, but I think this is important enough to avoid implementors confusion:

4.7.7.  Language Identifier

  A language identifier labels information content as being of a
  particular human language variant.  Following the XML specification
  for language identification [XML], a legal language identifier is
  identified by a RFC5646 ([RFC5646]) and RFC4647 ([RFC4647]) code
  where the language code is required and a country code or other
  subtag identifier is optional.

I would rather you delete "where the language code is required and a country code or other subtag identifier is optional". RFC 4647 specifies matching procedure for language tags (so an implementation that can only support the language codes can deal with language tags that contain more information). I think overriding RFC 4647 on this is at minimum confusing and at maximum even harmful.


Also, I've just noticed that the companion document doesn't have similar text. I think it should be added there as well.

[Ballot discuss]
[Updated as per version -12]

3) In 4.7.6.  MIME Media Type

  A string formated as an IANA MIME media type ([MIME.mediatypes]).
  The ABNF ([RFC5234]) production for the string is:

  type-name "/" subtype-name *(";" parameter-name)

  where "type-name" and "subtype-name" are defined in Section 4.2, and
  "parameter-name" in Section 4.3, of [RFC4288].

I don't think this ABNF is quite correct, as it doesn't allow for parameter values. Did you mean:

  A string formated as an IANA MIME media type ([MIME.mediatypes]).
  The ABNF ([RFC5234]) production for the string is:

  media-type = type-name "/" subtype-name *(";" parameter)

  parameter = parameter-name "=" value

  where "type-name" and "subtype-name" are defined in Section 4.2 of [RFC4288],
  "parameter-name" is defined in Section 4.3 of [RFC4288], and "value" is defined
  in Section 5.1 of [RFC2045].


5) BCP 18 (RFC 2277) requires that any human readable text is explicitly or implicitly tagged with a language tag. This affects the following fields in your document:

4.2.3. 

  reason:  string specifying a reason for the response status.  The
      attribute is optional.

4.2.4.2. 

  reason:  a textual description providing a reason for the status
      code; e.g. details about an error.  A valid value is a string (see
      Section 4.6.4).  The attribute is optional.  There is no default
      value.

4.2.4.3. 

  reason:  a textual description providing a reason for the status
      code; e.g. details about an error.  A valid value is a string (see
      Section 4.6.4).  The attribute is optional.  There is no default
      value.

4.3.2. 

  reason:  string specifying a reason for the status.  The attribute is
      optional.

I think the easiest way to address this would be to add xml:lang attribute to various identified places (and update the XML Schema accordingly), however other alternatives might be more suitable for you.
(See  for a bit more details)

Also note that some of the examples might have to be updated to show language tagging.

[Ballot discuss]
[Updated, adding issued # 5 below]

1) I would like to "upgrade" Peter's comment # 2 to DISCUSS:

There are XML errors in the text and examples, such as the following (a missing "/" in the second tag):

  mylayout:single-view

2) In 4.2.2.5.  :

  media:  a string indicating the type of media associated with the
      stream.  The following values MUST be used for common types of
      media: "audio" for audio media, and "video" for video media.  The
      attribute is mandatory.

(This is largely the same as Peter's COMMENT # 5)

Is there a registry (or at least a full list) of valid names?
Or did you mean the type part of a MIME type?

3) In 4.6.6.  MIME Media Type:

  A string formatted as a IANA MIME media type ([MIME.mediatypes]).

Firstly, I think this should also point to exact ABNF for this.
It is also not clear if Content-type parameters are allowed in this field.

For MIME type/subtype ABNF, please reference Section 4.2 of RFC 4288.
I would also encourage you to specify proper ABNF for this production (and to reference "type-name" and "subtype-name" from Section 4.2 of RFC 4288)

4)
4.2.2.5.3. 

  The  element is used to explicitly specify the region within
  a video layout where the media stream is displayed.

  The  element has no attributes and its content model
  specifies the name of the region layout.

I don't think this description is sufficient for understanding by somebody not involved in this work. Is there a good reference to add here?

5) BCP 18 (RFC 2277) requires that any human readable text is explicitly or implicitly tagged with a language tag. This affects the following fields in your document:

4.2.3. 

  reason:  string specifying a reason for the response status.  The
      attribute is optional.

4.2.4.2. 

  reason:  a textual description providing a reason for the status
      code; e.g. details about an error.  A valid value is a string (see
      Section 4.6.4).  The attribute is optional.  There is no default
      value.

4.2.4.3. 

  reason:  a textual description providing a reason for the status
      code; e.g. details about an error.  A valid value is a string (see
      Section 4.6.4).  The attribute is optional.  There is no default
      value.

4.3.2. 

  reason:  string specifying a reason for the status.  The attribute is
      optional.

I think the easiest way to address this would be to add xml:lang attribute to various identified places (and update the XML Schema accordingly), however other alternatives might be more suitable for you.
(See  for a bit more details)

Also note that some of the examples might have to be updated to show language tagging.

[Ballot discuss]
1) I would like to "upgrade" Peter's comment # 2 to DISCUSS:

There are XML errors in the text and examples, such as the following (a missing "/" in the second tag):

  mylayout:single-view

2) In 4.2.2.5.  :

  media:  a string indicating the type of media associated with the
      stream.  The following values MUST be used for common types of
      media: "audio" for audio media, and "video" for video media.  The
      attribute is mandatory.

(This is largely the same as Peter's COMMENT # 5)

Is there a registry (or at least a full list) of valid names?
Or did you mean the type part of a MIME type?

3) In 4.6.6.  MIME Media Type:

  A string formatted as a IANA MIME media type ([MIME.mediatypes]).

Firstly, I think this should also point to exact ABNF for this.
It is also not clear if Content-type parameters are allowed in this field.

For MIME type/subtype ABNF, please reference Section 4.2 of RFC 4288.
I would also encourage you to specify proper ABNF for this production (and to reference "type-name" and "subtype-name" from Section 4.2 of RFC 4288)

4)
4.2.2.5.3. 

  The  element is used to explicitly specify the region within
  a video layout where the media stream is displayed.

  The  element has no attributes and its content model
  specifies the name of the region layout.

I don't think this description is sufficient for understanding by somebody not involved in this work. Is there a good reference to add here?

[Ballot comment]
1. The  element is not very XML-friendly, given that it forces an implementation to parse through the XML character data. Currently the spec defines a format like this for XCON formats:

  dual-view-2x1-crop

Or like this for extensions

  mylayout:single-view

Have the authors considered a more XML-friendly approach, such as this?

 
   
 

 
    single-view
 

The specification could then instruct implementations to appropriately handle child elements that are qualified by other namespaces.

2. There are XML errors in the text and examples, such as the following (a missing "/" in the second tag):

  mylayout:single-view

3. In Section 4.2.1.4.3 the text has "The MS receives ,  and  commands" but the authors might mean "The MS receives ,  and  commands" or might not have intended to include the second  element.

4. Regarding the  element, see previous comments about .

5. Regarding the media attribute of the  element, a reference to http://www.iana.org/assignments/media-types/ would be appropriate. Also, are values other than "audio" and "video" allowed?

6. Please spell out the DTMF acronym on first use (Section 4.2.2.5.2).

7. In Section 4.6.1 the value space of boolean is defined as {true, false}, but does the lexical representation match that from W3 XML Schema, Section 3.2.2.1? It seems not, because the schema has:

   
     
       
       
     
   

Why define a special boolean datatype when W3 XML Schema already has xsd:boolean?

8. You might want to specify whether the schema is normative or informative.

9. The description of the default value for the 'tones' attribute does not match the schema.

[Ballot discuss]
1. The  element has a mixed content model:

  The  element content model (text and/or XML) is the value of
  the parameter.  Values in XML format MUST use a namespace other than
  the one used in this specification.  Note that a text value which
  contains XML characters (e.g. "<") needs to be escaped following
  standard XML conventions.

This seems inadvisable because it significantly complicates parsing. For instance, the following examples would be valid:

  234567

  123

  123567

  123567

Please justify the mixed content model or define a more reasonable approach, such as:

  123

and:

 

(but, possibly, never both  and something qualified by a foreign namespace)

[Ballot comment]
1. The  element is not very XML-friendly, given that it forces an implementation to parse through the XML character data. Currently the spec defines a format like this for XCON formats:

  dual-view-2x1-crop

Or like this for extensions

  mylayout:single-view

Have the authors considered a more XML-friendly approach, such as this?

 
   
 

 
    single-view
 

The specification could then instruct implementations to appropriately handle child elements that are qualified by other namespaces.

2. There are XML errors in the text and examples, such as the following (a missing "/" in the second tag):

  mylayout:single-view

3. In Section 4.2.1.4.3 the text has "The MS receives ,  and  commands" but the authors might mean "The MS receives ,  and  commands" or might not have intended to include the second  element.

4. Regarding the  element, see previous comments about .

5. Regarding the media attribute of the  element, a reference to http://www.iana.org/assignments/media-types/ would be appropriate. Also, are values other than "audio" and "video" allowed?

6. Please spell out the DTMF acronym on first use (Section 4.2.2.5.2).

7. In Section 4.6.1 the value space of boolean is defined as {true, false}, but does the lexical representation match that from W3 XML Schema, Section 3.2.2.1? It seems not, because the schema has:

   
     
       
       
     
   

Why define a special boolean datatype when W3 XML Schema already has xsd:boolean?

8. You might want to specify whether the schema is normative or informative.

9. The description of the default value for the 'tones' attribute does not match the schema.

[Ballot discuss]
1. The  element has a mixed content model:

  The  element content model (text and/or XML) is the value of
  the parameter.  Values in XML format MUST use a namespace other than
  the one used in this specification.  Note that a text value which
  contains XML characters (e.g. "<") needs to be escaped following
  standard XML conventions.

This seems inadvisable because it significantly complicates parsing. For instance, the following examples would be valid:

  234567

  123

  123567

  123567

Please justify the mixed content model or define a more reasonable approach, such as:

  123

and:

 

(but, possibly, never both  and something qualified by a foreign namespace)

[Ballot comment]
1. The  element is not very XML-friendly, given that it forces an implementation to parse through the XML character data. Currently the spec defines a format like this for XCON formats:

  dual-view-2x1-crop

Or like this for extensions

  mylayout:single-view

Have the authors considered a more XML-friendly approach, such as this?

 
   
 

 
    single-view
 

The specification could then instruct implementations to appropriately handle child elements that are qualified by other namespaces.

2. There are XML errors in the text and examples, such as the following (a missing "/" in the second tag):

  mylayout:single-view

3. In Section 4.2.1.4.3 the text has "The MS receives ,  and  commands" but the authors might mean "The MS receives ,  and  commands" or might not have intended to include the second  element.

4. Regarding the  element, see previous comments about .

5. Regarding the media attribute of the  element, a reference to http://www.iana.org/assignments/media-types/ would be appropriate. Also, are values other than "audio" and "video" allowed?

6. Please spell out the DTMF acronym on first use (Section 4.2.2.5.2).

7. In Section 4.6.1 the value space of boolean is defined as {true, false}, but does the lexical representation match that from W3 XML Schema, Section 3.2.2.1? It seems not, because the schema has:

   
     
       
       
     
   

Why define a special boolean datatype when W3 XML Schema already has xsd:boolean?

8. You might want to specify whether the schema is normative or informative.

9. The description of the default value for the 'tones' attribute does not match the schema.

[Ballot discuss]
1. The  element has a mixed content model:

  The  element content model (text and/or XML) is the value of
  the parameter.  Values in XML format MUST use a namespace other than
  the one used in this specification.  Note that a text value which
  contains XML characters (e.g. "<") needs to be escaped following
  standard XML conventions.

This seems inadvisable because it significantly complicates parsing. For instance, the following examples would be valid:

  234567

  123

  123567

  123567

Please justify the mixed content model or define a more reasonable approach, such as:

  123

and:

 

(but possibly, never both  and something qualified by a foreign namespace)

IANA comments:


IANA understands that some of the actions that would need to be
completed upon approval of this document depend on actions in other
Internet Drafts. Specifically, ietf-mediactrl-sip-control-framework.

Upon approval of this document IANA understands that it must complete
four actions.

First, in the Media Control Channel Framework Package sub-registry
created upon approval of ietf-mediactrl-sip-control-framework, a new
Control Channel Framework Package registration is to be created using
the template located in Section 8.1 of this document (specifically, IANA
understands that Section 12.1 of ietf-mediactrl-sip-control-framework
provides the instructions for creating a new Framework Package
registration).

Second, IANA is to register a new URN sub-namespace in the IANA XML
registry located at http://www.iana.org/assignments/xml-registry
/ns.html. The details of the registration are provided in section 8.2
of the document.

Third, IANA is to register a new XML schema in the IANA XML registry
located at http://www.iana.org/assignments/xml-registry/schema.html.
The details of the registration are provided in section 8.3 of the
document and the schema is provided in section 5 of the document.

Fourth, IANA will register a new MIME media type:

application/msc-mixer+xml

in the MIME registry located at:
http://www.iana.org/assignments/media-types/application/ using the
details provided in Section 8.4 of the document.

IANA understands that these four actions are the only ones it needs to
complete upon approval of the document.

IANA understands that some of the actions that would need to be
completed upon approval of this document depend on actions in other
Internet Drafts. Specifically, ietf-mediactrl-sip-control-framework.

IANA has two questions about the IANA Actions in this document. Upon
approval of this document IANA understands that it must complete four
actions.

First, in the Media Control Channel Framework Package sub-registry
created upon approval of ietf-mediactrl-sip-control-framework, a new
Control Channel Framework Package registration is to be created using
the template located in Section 8.1 of this document.

Second, IANA is to register a new URN sub-namespace in the IANA XML
registry located at http://www.iana.org/assignments/xml-registry
/ns.html. The details of the registration are provided in section 8.2
of the document.

IANA QUESTION:
what are the id and registration template names to be used for this
sub-namespace registration?

Third, IANA is to register a new XML schema in the IANA XML registry
located at http://www.iana.org/assignments/xml-registry/schema.html.
The details of the registration are provided in section 8.3 of the
document and the schema is provided in section 5 of the document.

IANA QUESTION: what are id and filename for this registration?

Fourth, IANA will register a new MIME media type:

application/msc-mixer+xml

in the MIME registry located at:
http://www.iana.org/assignments/media-types/application/ using the
details provided in Section 8.4 of the document.

IANA understands that these four actions are the only ones it needs to
complete upon approval of the document.

Document: A Mixer Control Package for the Media Control Channel Framework

draft-ietf-mediactrl-mixer-control-package-09

(Standards Track)

(1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Spencer Dawkins is the document shepherd. I have personally reviewed this
version of the document, and it is ready to forward to the IESG for
publication.

    (1.b) Has the document had adequate review both from key WG members
          and from key non-WG members? Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

This document was actually co-authored by many of the key WG members :-),
and the document has been closely reviewed by multiple implementation teams
(most recently at Broadsoft, and the Broadsoft team members were not
document authors).

Shawn Emery performed an early sec-dir review at the request of the chairs.

We held the MIXER back while Ben Campbell reviewed the IVR package (the
first MEDIACTL package to be sent for publication) for the RAI Area Review
Team. When we received feedback for IVR that was also applicable to the
MIXER control package, the editor modified the MIXER control package as
well.

    (1.c) Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No.

    (1.d) Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of? For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it. In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

None.

    (1.e) How solid is the WG consensus behind this document? Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

Strong consensus for publishing. This is one of two key control packages for
the entire working group.

The only contentious discussion we've had resulting from WGLC was whether
errors that occur in both IVR and MIXER should have the same error code.
After some discussion on the mailing list, Eric and I decided that this
wasn't a useful change, because most possible errors do not occur in more
than one package. We expect that error handlers must be written per-package
anyway, and this would have required us to pull the IVR control package
document back into the working group, for minimal gain.

    (1.f) Has anyone threatened an appeal or otherwise indicated  extreme
          discontent? If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director. (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

None.

    (1.g) Has the Document Shepherd personally verified that the
          document satisfies all ID nits? (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/). Boilerplate checks are
          not enough; this check needs to be thorough. Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

Checked with ID nits 2.11.05. The document generates a LOT of spurious nits,
because

- it uses square brackets to identify requirement labels, which look like
dangling references - but they aren't - and

- because the draft contains a "changes from previous versions" section with
a lot of section labels that look like (non-RFC 3330) IP addresses - but
they aren't - and

- because the draft includes XML attributes that look like (non-RFC 2606)
FQDNs - but they aren't.

All of these nits are spurious.

The document uses active tense in its 2119 boilerplate instead of the
passive voice most documents use.

    (1.h) Has the document split its references into normative and
          informative? Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state? If such normative references exist, what is the
          strategy for their completion? Are there normative references
          that are downward references, as described in [RFC3967]? If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

We do have normative and informative references. All normative references
are published except for the MEDIACTRL Control Framework (previously
submitted for publication), and there are no down-refs ([XML] is spurious).

    (1.i) Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

Yes, for all applicable questions :D

    (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

Implementers reported that they validated the XML schema using xerces-c 3.0
(Broadsoft) and XMLSpy (Meetecho).

    (1.k) The IESG approval announcement includes a Document
          Announcement Write-Up. Please provide such a Document
          Announcement Write-Up? Recent examples can be found in the
          "Action" announcements for approved documents. The approval
          announcement contains the following sections:

          Technical Summary

  This document defines a Media Control Channel Framework Package for
  managing mixers for media conferences and connections.  The package
  defines request elements for managing conference mixers, managing
  mixers between conferences and/or connections, as well as associated
  responses and notifications.  The package also defines elements for
  auditing package capabilities and mixers.

          Working Group Summary

Nothing out of the ordinary happened in the WG that was worth noting.

          Document Quality

This document has sufficient normative statements and examples for one
to create an implementation. There are at least four independent
implementations of the control package described by this document.

This document has been stable for several versions, with small changes in
each revision, discussed on the mailing list. Most of the recent changes
have been suggested based on implementer experience.