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

Magnus Westerlund <> Fri, 03 May 2019 09:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0C941200EF for <>; Fri, 3 May 2019 02:59:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 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] 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 u05hjBq9j5NU for <>; Fri, 3 May 2019 02:59:48 -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 43F4812006D for <>; Fri, 3 May 2019 02:59:48 -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=twrgjh8LB3Tt75nLXM6+kG81+eum7Kj98IYsE+6cEbw=; b=mY9eV6Andvy7nuGcSlqjOXreu9e8gi2jxtsfVNp/sY+z9QnvLPkRmCbeX64ZdCjt0mN0CthT6vUJjHNqqNQraIeIwDT4/oGFBfnGX9jB5TOE7ucB5TpLA73PqsCbnb4oNCS6hRq8moJyVKdHH1COQOzp7UTAB6vohwTgYmRmIVk=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.7; Fri, 3 May 2019 09:59:45 +0000
Received: from ([fe80::b161:fb77:e4ea:4723]) by ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1856.008; Fri, 3 May 2019 09:59:45 +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: Fri, 3 May 2019 09:59:44 +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: 64feee29-0483-4e35-a051-08d6cfae11f2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB3003;
x-ms-traffictypediagnostic: HE1PR0701MB3003:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0026334A56
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(396003)(136003)(366004)(199004)(189003)(6246003)(3846002)(2906002)(2171002)(33656002)(446003)(6116002)(81156014)(53936002)(9686003)(68736007)(76176011)(8676002)(81166006)(53546011)(6306002)(99286004)(5660300002)(6506007)(966005)(186003)(7696005)(14454004)(26005)(256004)(478600001)(14444005)(102836004)(52536014)(44832011)(25786009)(486006)(66946007)(229853002)(476003)(74316002)(7736002)(305945005)(316002)(66556008)(66066001)(110136005)(71190400001)(71200400001)(6436002)(86362001)(8936002)(66446008)(76116006)(2501003)(64756008)(73956011)(66476007)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB3003;; 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: bnI6qB0IpaPodc93S1cFEmIj3WYfD6aVyjo0rhv1uTD7UHPAwjj5OjpLZceHbGfCyYuBayUJcLwzh9inHFw3EKXScdc1EtACtY9Xg5AH19HQvh8NC49bHN7BcQmEOMXO2HcIwOh1pY/FUSf1/14xGvlVCa48Q5Tv/qGzMspaft1SNLR/zZf9ytK2V+2A0wEeMO8pfhCIpoz1CE5tklEeHCl3rXyEkUFekYayjq40Uy/+L310/rHhhHv0QGObaT+kKBK3ANFxYp/yRN7vgvgl84zL6LltVmbk+vvRRvUEr9kYkNQYUi0SYp8I8mcIuuwzIYTYUUU/XNAgKXVe5026NbBWjyem1IKnAIGn+Kr4N5Nc74k7iCBNrNXheLjrkKDDPG8dB0zEW9D9Up9POgVcLUvd5HeABGHc8ghmoVSh5Ww=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 64feee29-0483-4e35-a051-08d6cfae11f2
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2019 09:59:44.9834 (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: HE1PR0701MB3003
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: Fri, 03 May 2019 09:59:52 -0000


There appear that there are not much interest in this issue. I think if
there no one else that have input into this then there are not a problem
that affects anyone, but it also leaves things in an uncertain state,
but I guess that is what we will do.



On 2019-04-16 10:48, Magnus Westerlund wrote:
> 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
> 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: