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

[Magnus Westerlund <[e-mail]>]

Hi Paul,

If I attempt to interpret what you are saying as conclusion it has
several implications, or am I missunderstanding you?

1. Obsolete a=charset attribute. The only other options would be to
define a small set of attribute to which it applies like "i=".

2. Clarify section 5 that using UTF-8 characters without NUL, CR, LF in
attribute values and textual fields are okay.

3. Define how attribute values that may contain NUL, CR and LF use a
specified escaping mechanism

4. Define an escaping mechanism that applies to SDP and UTF-8 strings

5. Legacy warning in attempting to use escaping mechanism in old
attributes.

Is this a fair summary?

Cheers

Magnus



On 2019-04-12 17:45, Paul Kyzivat wrote:
> 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
>
> 	
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------