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

Magnus Westerlund <> Tue, 16 April 2019 08:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 31B1312046B for <>; Tue, 16 Apr 2019 01:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5Ei_i1xxn3Bc for <>; Tue, 16 Apr 2019 01:47:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CBCA120468 for <>; Tue, 16 Apr 2019 01:47:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l9bXLFE9h+iKzt08Jqo38GWvZQWclGAQGvWHmg5bGy8=; b=glxrcHe8Uab82z+MvU4xrWt/DTCgvhDcjPYzW1V3jNBpvDUIYyg/KiQBuaiEGgqoaCzPbLACbL/vkm7JhC/9EWqTca4/qTcNBywHQsDi8etcpRrnjmBhesOcdC6ickSycss4a9xYGrGHSov4QHmv0P0bvv4X9mOwuNE1WT31YiY=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Tue, 16 Apr 2019 08:47:25 +0000
Received: from ([fe80::b161:fb77:e4ea:4723]) by ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1813.009; Tue, 16 Apr 2019 08:47:25 +0000
From: Magnus Westerlund <>
To: Paul Kyzivat <>, "" <>
Thread-Topic: [MMUSIC] Last Call: <draft-ietf-mmusic-rfc4566bis-34.txt> (SDP: Session Description Protocol) to Proposed Standard
Thread-Index: AQHU4L35G0bkeH37hEyuzO/M/jMwpA==
Date: Tue, 16 Apr 2019 08:47:25 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
Accept-Language: sv-SE, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6885d9f5-74a3-402c-b8e1-08d6c2482641
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR0701MB2427;
x-ms-traffictypediagnostic: HE1PR0701MB2427:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 000947967F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(366004)(376002)(396003)(39860400002)(199004)(189003)(110136005)(53936002)(9686003)(256004)(3846002)(14444005)(6306002)(6246003)(2171002)(305945005)(52536014)(25786009)(476003)(486006)(8676002)(76176011)(66066001)(74316002)(966005)(446003)(81156014)(44832011)(5660300002)(14454004)(102836004)(7696005)(6506007)(186003)(86362001)(81166006)(26005)(53546011)(71200400001)(71190400001)(106356001)(68736007)(93886005)(33656002)(229853002)(316002)(8936002)(7736002)(6436002)(2501003)(99286004)(55016002)(478600001)(105586002)(6116002)(97736004)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2427;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: uG0PfYIaimjUXUBodAvBqMXf56zrsLU+tGnV/4RRXaOTEpBn3WkxIfQS3QGXviKNu50IJ/PjoeJWZyBCohCnjSIj0aUn2+NDkvwEFtGqVwX7qwVwVXfjw5O6fisnPKH78/35O74VRnZxXsjXNHhYp+dCsWbg9+6I97POmSH6MHdsPSVAaxgxakVAgSlK4MVDXzutKc5FgJgB6ghzeI9/yuyxexbv9vnaaVcP0vokJIX5XBhdojkOBwvQxMITLL0a93uKKhvipjvAParL67jmsBHd2x4UpandFeDlSPMjAG+018fMMardApSuaxSInq67Ay1DJPbG+qGd+CK1lEvD/4yp6BdWZVNW8jaIx0/r0zdkHLP4PVCT9C1nIC90Hwr28Lz1ktqcdwJaWOiOoeWzzpapX0uHr6nRNBo551OM/aI=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6885d9f5-74a3-402c-b8e1-08d6c2482641
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 08:47:25.2627 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2427
Archived-At: <>
Subject: Re: [MMUSIC] Last Call: <draft-ietf-mmusic-rfc4566bis-34.txt> (SDP: Session Description Protocol) to Proposed Standard
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Apr 2019 08:47:33 -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.



On 2019-04-16 01:17, Paul Kyzivat wrote:
> On 4/15/19 4:02 AM, Magnus Westerlund wrote:
>> 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=".
> 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.
>> 2. Clarify section 5 that using UTF-8 characters without NUL, CR, LF in
>> attribute values and textual fields are okay.
> That would amount to limiting charset to UTF-8, which is same as 
> deprecating it. 

>> 3. Define how attribute values that may contain NUL, CR and LF use a
>> 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.
>> 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.
> 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
>> 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 (
>>>      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
> _______________________________________________
> mmusic mailing list


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: