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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 11 Apr 2019 08:14:26 +0000

MMUSIC WG, Document Editors

In the processing of draft-ietf-mmusic-data-channel-sdpneg-25 an interesting question arose regarding text strings in SDP attribute values.

Currently the document says:

4.5.  Internationalization

   The SDP specification recommends the use of the ISO 10646 character
   set in the UTF-8 encoding [RFC3629] to allow many different languages
   to be represented.  However, to assist in compact representations,
   SDP also allows other character sets such as ISO 8859-1 to be used
   when desired.  Internationalization only applies to free-text sub-
   fields (session name and background information), and not to SDP as a
   whole.

If one like to include UTF-8 field for attributes it would be good if
the requirement would be clear going forward that there is an expectancy
that at least parser can process any UTF-8 strings that may occur in any
fields.

That would allow future SDP field values to use UTF-8 strings without risks
and simplify processing. Like in the case of the data channel SDP mapping
where the extra step of encoding lable characters not visually safe as escaped
characters could be avoided.

Does anyone have input if making such a change would have significant impact on
the interoperability?

Cheers

Magnus

On 2019-03-22 15:46, The IESG wrote:

The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document: - 'SDP: Session
Description Protocol'
  <draft-ietf-mmusic-rfc4566bis-34.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> mailing lists by 2019-04-12. Exceptionally, comments may be
sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   This memo defines the Session Description Protocol (SDP).  SDP is
   intended for describing multimedia sessions for the purposes of
   session announcement, session invitation, and other forms of
   multimedia session initiation.  This document obsoletes RFC 4566.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ballot/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

--

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 11 Apr 2019 10:04:41 +0000

Hi Magnus,
I think it will affect the IANA registries where values may be shared with non SDP attribute. For example the sub-protocol in the IANA WebSocket Subprotocol name registry

Roni Even

From: mmusic [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Thursday, April 11, 2019 11:14 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Last Call: <draft-ietf-mmusic-rfc4566bis-34.txt> (SDP: Session Description Protocol) to Proposed Standard

   whole.

fields.

the interoperability?

Cheers

Magnus

Description Protocol'

Abstract

mmusic mailing list

--

Magnus Westerlund

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Apr 2019 12:08:47 -0400

On 4/11/19 4:14 AM, Magnus Westerlund wrote:
> In the processing of draft-ietf-mmusic-data-channel-sdpneg-25 an 
> interesting question arose regarding text strings in SDP attribute values.
> 

I'm inclined to just say that attribute values are limited to values 
that are natively representable in the chosen charset. That will impose 
limitations on use with charsets more limited than UTF-8.

	Thanks,
	Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 12 Apr 2019 08:59:48 +0000

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.

Cheers

Magnus Westerlund
(As Individual)

On 2019-04-11 12:05, Roni Even (A) wrote:
Hi Magnus,
I think it will affect the IANA registries where values may be shared with non SDP attribute. For example the sub-protocol in the IANA WebSocket Subprotocol name registry

Roni Even

From: mmusic [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Thursday, April 11, 2019 11:14 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] Last Call: <draft-ietf-mmusic-rfc4566bis-34.txt> (SDP: Session Description Protocol) to Proposed Standard

   whole.

fields.

the interoperability?

Cheers

Magnus

Description Protocol'

Abstract

mmusic mailing list

--

Magnus Westerlund

--

Magnus Westerlund

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Apr 2019 11:45:24 -0400

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 15 Apr 2019 08:02:51 +0000

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:
> [email-masked]

-- 

Magnus Westerlund 

SE-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Apr 2019 19:15:40 -0400

> define a small set of attribute to which it applies like "i=".

That is what I am suggesting. I can't see how it ever could have worked 
*in general* for arbitrary charset values. And at this point I don't see 
a need.

Alternatively, restrict the charsets which can work to those which have 
some benign values.

IMO the most troublesome charsets are those that are wider than one 
byte, like UTF-16 or UTF-32, since they would have to coexist with the 
rest of the sdp being the ascii subset of UTF-8. Also troublesome are 
charsets not vaguely related to ascii, like the variants of EBCDIC.

> attribute values and textual fields are okay.

That would amount to limiting charset to UTF-8, which is same as 
deprecating it.

> specified escaping mechanism

Right now it says that the charset must define an escaping mechanism, 
without saying how that might happen. AFAIK *none* of the charsets 
define an escaping mechanism.

But I also don't see how one could define such a mechanism independent 
of the charset since it must presumably reserve some character(s) from 
that charset to introduce the escape.

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

Not sure what to say about 4 & 5.

> Is this a fair summary?

Whatever.

I'm hoping I'm missing something about how this was intended to work in 
the first place.

	Thanks,
	Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 16 Apr 2019 08:47:25 +0000

Hi Paul,

I think this needs input from more people.

I did make a mistake in my thinking about the charset encodings. With
UTF-8 there are only US-ASCII that are a pure sub-set of UTF-8 when
encoded. So you are right about the implications.

Cheers

Magnus

-- 

Magnus Westerlund