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

[Paul Kyzivat <[e-mail]>]

Alexey,

Thank you for your careful review and comments. I've included some 
followup for you inline below.

On 5/30/19 8:50 AM, Alexey Melnikov via Datatracker wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-mmusic-rfc4566bis-35: No Objection

> ----------------------------------------------------------------------
> 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.

I don't understand. This paragraph is referencing examples of protocols 
that can be used to *transport* SDP. RFC5322 references the mail message 
format that would be used to encapsulate SDP if it were transported via 
email. (Though it doesn't actually mention the *transport* protocols 
used for mail messages.)

ISTM that it is the containing protocols that should reference rfc2045. 
RFC5322 does so, and so says how to carry SDP in mail messages. SIP is 
itself effectively an extension to RFC2045 though it doesn't say so.

I don't object to adding a reference to RFC2045, I just don't know how 
to fit it in appropriately.

> 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?

IIUC this is simply an escape hatch for unusual types of media. 
Currently there are no *media types* that redefine this. In reality, the 
case where address and port are impacted is with <nettype> and 
<addrtype>s that don't have the same notion of address and port. For 
instance, RFC7195 defines a way of specifying circuit switched PSTN 
connections, using <nettype> PSTN and <addrtype> E164. These are used 
with existing <media> audio. There is no notion of port here. To comply 
with syntax requirements is calls for using port 9.

I will try to rework the text here to explain the situation more generally.

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

OK

> In 4.5: ISO 8859-1 needs a reference.

OK.

> 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.

I agree. Will change.

> In 5.5:
> 
> “WWW clients“
> 
> URIs are used by many types of clients. Suggest dropping “WWW”.

OK. Another legacy from 20 years ago.

> 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.

Agree. Will change.

We have recently had some discussion of a=charset. It seems that the 
intent is lost in time and we are left trying to infer it.

I don't recall what the state of character set definitions was in 1998 
when this was first published. But it appears that they got carried away 
and over-generalized. It is easy to understand how one might choose to 
use ISO 8859-1 rather than UTF-8 since they are closely related and 
byte-oriented. But it is unclear how one might use some other registered 
charsets, such as EBCDIC, or other encodings of ISO 10646, such as UTF-16.

The bottom line is that use of alternate charsets other than 8859-1 is 
underspecified. We considered revamping the definition of charset, but 
didn't want to open that can of worms, since in practice it isn't an issue.

> 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?

I don't know what the original authors had in mind, but I assume so.

> Can you point to a specific ABNF in RFC 5646?

This section already says:

              sdplang-value = Language-Tag
              ; Language-Tag defined in RFC5646

Doesn't that cover it?

> Also, “in the US-ASCII subset of UTF-8“ is either redundant or confusing, as
> language tags are always in U-ASCII.

I'll take it out.

> 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.

OK. It appears that 8bit is appropriate 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?

I don't believe there is any intent to exclude this.