Subject: [MMUSIC] Errata report on errata 2338 for RFC 5245, "Interactive Connectivity Establishment (ICE)"

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 2 Dec 2010 14:00:42 -0500

======================================================================
RFC5245, "Interactive Connectivity Establishment (ICE)"
Source of RFC: mmusic (rai)

Errata ID: 2338

Status: Reported
Type: Technical

Reported By: Reif, Frank
Date Reported: 2010-07-20

Section 15.1 says:

extension-att-name    = byte-string    ;from RFC 4566

It should say:

extension-att-name    = token    ;from RFC 4566

Notes:

"extension-att-name" may contain the SP (0x20) as defined for
"byte-string" in RFC 4566.
The 'SP' character cannot be allowed within "extension-att-name" as it
is also used as delimiter between "extension-att-name" and
"extension-att-value".
----------------------------------------------------------------------
Recommended status:  Verified (publish)

The same analysis holds for "extension-att-value".

It would make far more sense if the two productions were:

   extension-att-name    = non-ws-string    ;from RFC 4566
   extension-att-value   = non-ws-string

Given that the definitions of "byte-string" and "non-ws-string" are
adjacent in RFC 4566, it appears that the latter is what was meant by
the author.
======================================================================

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 3 Dec 2010 10:06:14 +0100

Hi,

That is probably fine, but I would like to point out that this enables
full UTF-8 set of characters in both name and values of the attribute
value pair. I don't see an issue with that but some may?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 6 Dec 2010 16:13:44 -0500

> From: Magnus Westerlund [[email-masked]]
> 

The base specification for SDP is RFC 4566.  Sections 4.6 and 5 specify that an SDP document is a sequence of characters, with the preferred character set/encoding being ISO 10646/UTF-8, but also admitting ISO-8859-1 (presumably in the standard 1-byte encoding).  But the BNF definitions on page 43 (e.g., byte-string, non-ws-string, token-char, and email-safe) sleaze the specification.  I believe that the intention is that byte values x00 through x7F are assumed to encode the standard ASCII characters, and byte values x80 through xFF are assumed to be used to encode other "non-special" characters, either singly (e.g., ISO 8859-x) or in groups (e.g., ISO 10646/UTF-8).  This is a serious layer violation between the "characters represented by code points" and "code points encoded as bytes" layers, but people do that all the time, and it allows one to make a simple parser that can correctly decode many popular encoding systems.

Within that understanding, I expect that the extension attribute productions listed above are intended to permit using "all other" characters in the character set of the particular SDP document to be used in extension attribute names and values.  And RFC 4566 gives implicit instructions for parsing the document.  And that interpretation does not seem to cause any additional difficulties.

As a design question, I would restrict extension-att-name to a more restricted character set (e.g., token-char).  But the text of RFC 5245 uses the same definition for extension-att-name and extension-att-value, so I don't think a limitation of that sort was intended.

Dale