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

[Paul Kyzivat <[e-mail]>]

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:
> Hi, Paul.  Sticking my oar in with Alexey's here, just on a couple of items:
> 
>>> 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.
> 
> 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.
> 
>>> 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.
> 
> 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
> 
>> 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