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

[Barry Leiba <[e-mail]>]

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

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