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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 11 April 2019 16:08 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927EC120308; Thu, 11 Apr 2019 09:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsFegBqlg_4M; Thu, 11 Apr 2019 09:08:56 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62891202E5; Thu, 11 Apr 2019 09:08:53 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x3BG8mTG003643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Apr 2019 12:08:48 -0400
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "ietf@ietf.org" <ietf@ietf.org>
Cc: Adam Roach <adam@nostrum.com>, "draft-ietf-mmusic-rfc4566bis@ietf.org" <draft-ietf-mmusic-rfc4566bis@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>
References: <155326592304.23020.8256337045285295468.idtracker@ietfa.amsl.com> <HE1PR0701MB2522795AFC19AB4A73D65ABA952F0@HE1PR0701MB2522.eurprd07.prod.outlook.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <7909c1bc-b204-268a-3b81-8e65b9fd2dda@alum.mit.edu>
Date: Thu, 11 Apr 2019 12:08:47 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <HE1PR0701MB2522795AFC19AB4A73D65ABA952F0@HE1PR0701MB2522.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/_RYPHQuHC7eN83Kv2YK7D94-130>
Subject: Re: [MMUSIC] Last Call: <draft-ietf-mmusic-rfc4566bis-34.txt> (SDP: Session Description Protocol) to Proposed Standard
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 16:09:00 -0000

On 4/11/19 4:14 AM, Magnus Westerlund wrote:
> 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?

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