Re: [MMUSIC] Last Call: <draft-ietf-mmusic-rfc4566bis-34.txt> (SDP: Session Description Protocol) to Proposed Standard

[Paul Kyzivat <[e-mail]>]

On 4/12/19 4:59 AM, Magnus Westerlund wrote:
> Hi,
> 
> To be clear, I am not proposing that any existing attribute would be 
> forced to suddenly accept UTF-8 strings with no charset restriction. 
> Simply that new attribute's values can be defined to be UTF-8 in 
> general. I think the important distinction here is that a parser must be 
> ready to accept any UTF-8 character as the sender can't know if a 
> particular charset limitation applies to a specific consumer. However, 
> in form I don't see a problem of the SDP itself informing the consumer 
> that there is a charset limitation applied in this document.
> 
> My interpretation of the current situation is that it we hesitate to use 
> UTF-8 fields due to the uncertainty in the requirements on consumers of 
> SDP.

After re-reviewing the text, I think we may have a can of worms here 
that has existed a long time, perhaps from the beginning. Let me explain:

Section 5 says:

    An SDP description is entirely textual.  SDP field names and
    attribute names use only the US-ASCII subset of UTF-8, but textual
    fields and attribute values MAY use the full ISO 10646 character set
    in UTF-8 encoding, or some other character set defined by the
    "a=charset:" attribute.

Section 6.10 (charset attribute) says:

    The charset specified MUST be one of those registered in the IANA
    Character Sets registry (http://www.iana.org/assignments/character-
    sets), such as ISO-8859-1.
    ...
    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.

The charsets registry has a *lot* of entries, including a lot of ancient 
obsolete ones not vaguely related to ascii. (E.g., EBCDIC-related ones.) 
Many of these refer to RFC1345, which seems to be a pre-unicode attempt 
to rationalize character sets. The charsets registry also includes 
UTF-16 and UTF-32. It is really hard to understand how certain parts of 
an SDP body might be in UTF-8 while other parts are in UTF-32.

I can't make any sense of:

    Character sets requiring
    the use of these characters MUST define a quoting mechanism that
    prevents these bytes from appearing within text fields.

AFAIK character sets don't define quoting mechanisms. Also, I don't know 
what it means for a charset to require use of particular characters. And 
this text is very sloppy in muddling the use of "character" and "byte".

The bottom line is that this is a mess. I'm not sure if it ever could 
have worked. Nor do I understand what usage it was trying to 
accommodate. (Note that most of this stuff is largely unchanged since 
RFC2327.)

Perhaps all the charset-dependent stuff should be obsoleted.

	Thanks,
	Paul