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

From: Paul Kyzivat <[email-masked]>
Date: Mon, 3 Jun 2019 13:24:18 -0400

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.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 3 Jun 2019 21:54:28 +0200

> itself effectively an extension to RFC2045 though it doesn't say so.

Alexey's point is that you explicitly mention "MIME extensions" and
don't provide a reference for it.  I'll go a bit farther to say that
you're not just talking about message *format* here, but also SMTP as
the transport (more correctly, application-layer) protocol, yes?  So
this should say something more like, "electronic mail [RFC5321] using
the MIME extensions [RFC2045]".  I don't think you need 5322, because
822 is cited by 2045, and that is obsoleted by 2822, and that by 5322.
But I think you do need to cite SMTP and MIME.

> > characters MUST NOT be used in values.

Adding to what Alexey says, and maybe clarifying a bit: Character set
and encoding are different things.  The character set is the
abstraction of the characters used, and the encoding is how they're
represented.  The encoding is what creates the bytes on the wire.  One
problem is that "ASCII" refers to both, so it's confusing.  But with
Unicode, "Unicode" is the character set and "UTF-8" is (usually) the
encoding.

But your point here is that the three byte values you list MUST NOT
appear in the string, and that has nothing to do with the character
set or the encoding.  Those three bytes are prohibited.

You say that quite well in Section 5:

   Text-containing fields such as the session-name-field and
   information-field are octet strings that may contain any octet with
   the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII
   carriage return).

... and in 5.13:

   Attribute values are octet strings, and MAY use any octet value
   except 0x00 (Nul), 0x0A (LF), and 0x0D (CR).

But in 6.10 I think you want something more like this:

OLD
   Note that a character set specified MUST still prohibit the use of
   bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR).  Character sets requiring
   the use of these characters MUST define a quoting mechanism that
   prevents these bytes from appearing within text fields.
NEW
   Note that the restriction specified in Section 5 applies: these strings
   MUST NOT contain the bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR).
   Character encodings that use these bytes MUST define a quoting
   mechanism that prevents these bytes from appearing within the text
   strings.
END

> didn't want to open that can of worms, since in practice it isn't an issue.

I appreciate that, and I think this isn't the place to tackle that.
So we just need to get the text here to accurately reflect what you're
trying to say.

Hoping to be helpful,
Barry

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 3 Jun 2019 16:18:00 -0400

Barry,

Thank you for sticking your oar in. I think I can use your text.

	Thanks,
	Paul

On 6/3/19 3:54 PM, Barry Leiba wrote:
>> charsets, such as EBCDIC, or other encodings of ISO 10646, such as UTF-16

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 4 Jun 2019 12:35:14 -0400

I'm working on resolving IESG comments on rfc4566bis. I need some help 

>> draft-ietf-mmusic-rfc4566bis-35: No Objection

...

>> In 3.1 “media types” need a Normative reference.

I've always struggled on this. The "simple" answer to refer to RFC2046. 
That indeed defines the notion of two part names for media types, and 
the IANA registry for those. But it is really focused primarily on those 
things that can exist as body parts in email, sip, etc. While that same 
registry is used for streaming media, it seems clear that not everything 
in that registry is suitable for use as streaming media.

Is there a more suitable reference for definition of the media types 
that SDP is concerned with?

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Tue, 4 Jun 2019 18:13:41 +0100

> On 4 Jun 2019, at 17:35, Paul Kyzivat <[email-masked]> wrote:
> I'm working on resolving IESG comments on rfc4566bis. I need some help on this one:
> 
> I've always struggled on this. The "simple" answer to refer to RFC2046. That indeed defines the notion of two part names for media types, and the IANA registry for those. But it is really focused primarily on those things that can exist as body parts in email, sip, etc. While that same registry is used for streaming media, it seems clear that not everything in that registry is suitable for use as streaming media.
> 
> Is there a more suitable reference for definition of the media types that SDP is concerned with?

RFC 2046 is obsolete. I think the current version is RFC 6838.

Aside from that, I’m not sure I understand the concern. SDP is a general purpose signalling protocol and should be able to negotiate any media type. Specific rules for framed media, such as RTP payload formats, are described in Section 4.8 of RFC 6838, but those are a detail that doesn’t affect SDP.

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 4 Jun 2019 14:22:56 -0400

> Aside from that, I’m not sure I understand the concern. SDP is a general purpose signalling protocol and should be able to negotiate any media type. Specific rules for framed media, such as RTP pay…

Do you mean that it would be fine to use SDP to negotiate the streaming 
of multipart/mixed or text/plain over RTP?

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 4 Jun 2019 13:42:43 -0500

[as an individual]

On 6/4/19 1:22 PM, Paul Kyzivat wrote:
>>> I've always struggled on this. The "simple" answer to refer to 
>>> RFC2046. That indeed defines the notion of two part names for media 
>>> types, and the IANA registry for those. But it is really focused 
>>> primarily on those things that can exist as body parts in email, 
>>> sip, etc. While that same registry is used for streaming media, it 
>>> seems clear that not everything in that registry is suitable for use 
>>> as streaming media.
>>>
>> Aside from that, I’m not sure I understand the concern. SDP is a 
>> general purpose signalling protocol and should be able to negotiate 
>> any media type. Specific rules for framed media, such as RTP payload 
>> formats, are described in Section 4.8 of RFC 6838, but those are a 
>> detail that doesn’t affect SDP.
>
> Do you mean that it would be fine to use SDP to negotiate the 
> streaming of multipart/mixed or text/plain over RTP? 

As fine as it would be to send an email with a Content-Type of 
"application/sdp".

If someone came along and somehow defined semantics for these, then the 
syntax and registration processes would support that. But MIME doesn't 
do anything to ensure semantic consistency: there are infinite ways to 
send nonsense.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 4 Jun 2019 15:07:09 -0400

OK, thanks. Then I guess it is 6838.

	Thanks,
	Paul

On 6/4/19 2:42 PM, Adam Roach wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Tue, 4 Jun 2019 20:26:17 +0100

> On 4 Jun 2019, at 19:22, Paul Kyzivat <[email-masked]> wrote:
> Do you mean that it would be fine to use SDP to negotiate the streaming of multipart/mixed or text/plain over RTP?

I doubt the media type for multipart/mixed defines how it should be carried over RTP so it wouldn’t make sense to negotiate that, but SDP should be able to express it as an option. 

Sending text/plain in RTP might make sense as a timed text format, although the text payload formats we have include richer information and use different media types.

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 4 Jun 2019 15:44:17 -0400

On 6/4/19 3:26 PM, Colin Perkins wrote:
>> On 4 Jun 2019, at 19:22, Paul Kyzivat <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>>> On 4 Jun 2019, at 17:35, Paul Kyzivat <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
> I doubt the media type for multipart/mixed defines how it should be 
> carried over RTP so it wouldn’t make sense to negotiate that, but SDP 
> should be able to express it as an option.

That is what I was getting at: ISTM that only those that specify how 
they can be carried over RTP, or some other <proto> valid in an m-line, 
are appropriate for use.

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Tue, 4 Jun 2019 20:48:14 +0100

> On 4 Jun 2019, at 20:44, Paul Kyzivat <[email-masked]> wrote:
>>> On 4 Jun 2019, at 19:22, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> On 4 Jun 2019, at 17:35, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
> That is what I was getting at: ISTM that only those that specify how they can be carried over RTP, or some other <proto> valid in an m-line, are appropriate for use.

Not everything makes sense to use, but a general purpose negotiation protocol should allow you to express the possibility.

-- 
Colin Perkins
https://csperkins.org/

---

From: "Alexey Melnikov" <[email-masked]>
Date: Fri, 07 Jun 2019 13:09:57 +0100

Hi Barry/Paul,

> But I think you do need to cite SMTP and MIME.

Yes, exactly.

> Unicode, "Unicode" is the character set and "UTF-8" is (usually) the

Right. And the term "charset" is encoding of a particular character set. It might be worth using it below.

>    mechanism that prevents these bytes from appearing within the text

I think this is much better, although "use these bytes" is still ambiguous. E.g. if these bytes are used to shift between encoding modes within a particular charset, then there is a problem. If they are just used to convey specific characters, it might not be.

However, see my comment below.

> So we just need to get the text here to accurately reflect what you're

I would actually suggest that the document should tighten the definition of which charsets are allowed. For textual media types we now recommend use of UTF-8 (which should be the default) and possibly allowing a few others.

So I suggest that the new definition of a=charset be along the lines of "MUST support UTF-8 and US-ASCII. MAY support ISO-8859-1. SHOULD NOT use any other charsets".

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 7 Jun 2019 10:24:50 -0400

Alexy,

When we first realized the issues with charset we thought we were very 
near the end of these revisions, and there didn't seem to be much taste 
for opening this can of worms. But the collection of iesg comments have 
led me to do a fair number of revisions. So I will ask again if there is 
willingness to make this kind of change. The main concern is with 
backward compatibility - is there any use in the wild of other charsets. 
I doubt it, but don't have any data to back that up.

(The whole a=charset thing is a pain without much gain. Much trouble 
identifying things that are and aren't charset-dependent.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 7 Jun 2019 10:38:07 -0400

MMUSIC SDP fans,

The message below already went to mmusic, but here I'm reducing the 
distribution list to only mmusic so we don't spam the iesg with our 
internal discussion.

It seems that Alexy doesn't want to let us sweep the charset issues 
under the rug.

Would his suggestion to restrict the charsets permitted to be used be 

	Thanks,
	Paul

On 6/7/19 10:24 AM, Paul Kyzivat wrote:
>> I think this is much better, although "use these bytes" is still 
>> ambiguous. E.g. if these bytes are used to shift between encoding 
>> modes within a particular charset, then there is a problem. If they 
>> are just used to convey specific characters, it might not be.
>>
>> I would actually suggest that the document should tighten the 
>> definition of which charsets are allowed. For textual media types we 
>> now recommend use of UTF-8 (which should be the default) and possibly 
>> allowing a few others.
>>
>> So I suggest that the new definition of a=charset be along the lines 
>> of "MUST support UTF-8 and US-ASCII. MAY support ISO-8859-1. SHOULD 
>> NOT use any other charsets".
>>
>>> Hoping to be helpful,
>>> Barry
>>>
>>
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 8 Jun 2019 10:38:39 +0100

Hi Paul,

> On 7 Jun 2019, at 15:24, Paul Kyzivat <[email-masked]> wrote:
> 
> Alexy,
> 
> When we first realized the issues with charset we thought we were very near the end of these revisions, and there didn't seem to be much taste for opening this can of worms. But the collection of iesg comments have led me to do a fair number of revisions. So I will ask again if there is willingness to make this kind of change. The main concern is with backward compatibility - is there any use in the wild of other charsets. I doubt it, but don't have any data to back that up.

For new applications there is no need to support anything other than UTF-8.
But of course this doesn’t help you. In email space there is still quite a lot of non UTF-8 support, but this is mostly due to legacy code.

If it was me, I was just bite the bullet and at least start phasing out non UTF-8 (that is why I suggested “SHOULD NOT use any other charset”). If you don’t start now, you will never be able to deprecate them.

But of course this is for the WG to decide.
> 
> (The whole a=charset thing is a pain without much gain. Much trouble identifying things that are and aren't charset-dependent.)

I can see that :-)

Best Regards,
Alexey

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 8 Jun 2019 17:52:43 +0000

Hi,

I don't have a strong opinion, but I would really like to avoid a "MUST-MAY-SHOULD NOT" definition.

One bold approach would be to only allow, and mandate support of, a set of charsets. The definition and usage of any additional charsets need to be defined in a separate document.

Regards,

Christer

On 07/06/2019, 17.38, "mmusic on behalf of Paul Kyzivat" <[email-masked] on behalf of [email-masked]> wrote:

    MMUSIC SDP fans,

    

    	Thanks,
    	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 8 Jun 2019 18:11:37 -0400

> One bold approach would be to only allow, and mandate support of, a set of charsets. The definition and usage of any additional charsets need to be defined in a separate document.

While I think it would be possible to restrict what any new usages do, 
the problem is covering existing usages. (Even though this may be a 
non-existent problem.)

ISTM there is an interesting problem when using any charset that 
includes multibyte sequences. A charset-dependent part always begins 
midway through a line, and consists of a byte-string followed by CR LF. 
The byte-string consists of a sequence of bytes not including NUL, CR, LF.

This means that anywhere that the syntax resolves to byte-string, it 
allows sequences of bytes that may not be valid in the charset in which 
that is interpreted. This is *not* a syntax error. But presumably this 
should be treated as a semantic error in context. This is not currently 
called out anywhere. Seems like it should be.

Maybe if we call out this problem, it can be considered to resolve the 
problem of the ambiguity in using troublesome charsets such as UTF-16. 
But this isn't just a problem with non-default charsets - it can also 
occur with UTF-8. If this is good enough then it is a simple solution to 
the problem.

	Thanks,
	Paul