[MMUSIC] Alexey Melnikov's No Objection on draft-ietf-mmusic-rfc4566bis-35: (with COMMENT)

[Alexey Melnikov via Datatracker <[e-mail]>]

Alexey Melnikov has entered the following ballot position for
draft-ietf-mmusic-rfc4566bis-35: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for a well written document. Below are mostly nits, but I think they
will help first time implementors.

In Section 1:

electronic mail using the MIME   extensions [RFC5322]

This needs another reference for MIME. E.g. RFC 2045.

In 3.1 “media types” need a Normative reference.

In 4.1:

 Some media types may   redefine this behavior, but this is NOT RECOMMENDED
 since it complicates implementations (including middleboxes that must parse  
 the addresses to open Network Address Translation (NAT) or firewall  
 pinholes).

Can you give an example of such redefinition?

In 4.3: the first mention of URI needs a Normative Reference.

In 4.5: ISO 8859-1 needs a reference.

In 5.3:

   The "s=" line MUST NOT be empty and SHOULD contain ISO 10646
   characters (but see also the "a=charset" attribute)

Does this mean that it is affected by a=charset?
Why SHOULD?
The text is 5.4 is better, if the intention is the same.

In 5.5:

“WWW clients“

URIs are used by many types of clients. Suggest dropping “WWW”.

In 6.10:

   Note that a character set specified MUST still prohibit the use of
   bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR).

This doesn’t actually say what you intended. None of the common charsets
prohibit these bytes. I think you meant that when using such charsets, these
characters MUST NOT be used in values.

In 6.11:

   The "sdplang" attribute value must be a single [RFC5646] language tag
   in the US-ASCII subset of UTF-8

Is “fr-ca” allowed here?
Can you point to a specific ABNF in RFC 5646?
Also, “in the US-ASCII subset of UTF-8“ is either redundant or confusing, as
language tags are always in U-ASCII.

In 8.1:

  Encoding considerations:         SDP files are primarily UTF-8 format text

This is not correct use of this field. I think you should say “8bit” or
“binary” here.

In 8.2.2:

   Registrations MUST reference an RFC describing the protocol.
   Such an RFC MAY be Experimental or Informational, although it is
   preferable that it be Standards Track.

I just want to confirm that an Independent Stream RFC is allowed here?