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

Magnus Westerlund <> Mon, 15 April 2019 08:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8C2812009C for <>; Mon, 15 Apr 2019 01:02:57 -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 dL0G7O39n60F for <>; Mon, 15 Apr 2019 01:02:55 -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 C279112004B for <>; Mon, 15 Apr 2019 01:02:54 -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=XczIKExSrIMOGbs3vGsJ870G+FOzCh4b/pSWPVMEA0A=; b=dZhcVlAl/CU2wymLnjg+Fb7IxQsyF+rZ6HGwC3KtztBae4pJgcjJ4WUyFmI+Fl/t2S2kHLMcEYXVvtjE3+ynsKOpdWpU4X36btmjF2frNdVxzYJLrffFQM4Vq2YQxvx9aTslfTZxjjv81/zKOsZVXZnOe1R9aTVCjhlQ64IfiU0=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Mon, 15 Apr 2019 08:02:51 +0000
Received: from ([fe80::b161:fb77:e4ea:4723]) by ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1813.009; Mon, 15 Apr 2019 08:02:51 +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: Mon, 15 Apr 2019 08:02:51 +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: 2a0d5bb4-5ee2-428e-3ebf-08d6c178c23e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR0701MB2444;
x-ms-traffictypediagnostic: HE1PR0701MB2444:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 000800954F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(39860400002)(366004)(376002)(396003)(189003)(199004)(71190400001)(2501003)(81156014)(81166006)(14454004)(305945005)(8676002)(93886005)(446003)(66066001)(8936002)(5660300002)(7736002)(71200400001)(74316002)(6436002)(486006)(476003)(229853002)(52536014)(86362001)(53546011)(7696005)(316002)(105586002)(106356001)(99286004)(76176011)(53936002)(55016002)(25786009)(14444005)(102836004)(6506007)(256004)(9686003)(6306002)(26005)(68736007)(44832011)(2906002)(3846002)(6116002)(6246003)(478600001)(97736004)(33656002)(966005)(186003)(2171002)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2444;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: kX+ThB+GMBSdFxmPrfDaeRxl6w+pzCfaleD/HL7dlZY7ZjakYAsjI34im77YSG41171Dq0fdIOQIlZ/V5vTEJdubtQmuA0EjejswNXGlNbIZnAJ5xB0vbPtWRxU9cCDuzKn1qbXg4IKGr2xALh2U8biaRL7ur/ncvVVw3r8JsidosXa2HsStnO5uu8F3h1qRoUPhNuihwaQDS+VN7n2fc9RdvkNQwRepEj39YLp+CcQPFJtvbidievCVAXpQ9RWrg5P7Ap6xBo2C8raw9n0QwJHk2RGd3kkYNST1H7vQmx+dtCF5e6NQTYY6CRSQlW3wDlWtcEzj5uX/bPAU4Jkew/lMcGQTOFNtQ7csczz0Pr8Ti3deBRYwCr0XpjgKjuYgXxvT4lMD0uYKPgAhyVppDkRumc+Z35Hyn/0/T/iQ6CU=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a0d5bb4-5ee2-428e-3ebf-08d6c178c23e
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 08:02:51.7058 (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: HE1PR0701MB2444
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: Mon, 15 Apr 2019 08:02:58 -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

Is this a fair summary?



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


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: