[MMUSIC] RID Open Issue #3: Escaping in Extension Parameters

Adam Roach <adam@nostrum.com> Fri, 11 March 2016 18:46 UTC

Return-Path: <adam@nostrum.com>
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 B1C8F12DA4F for <mmusic@ietfa.amsl.com>; Fri, 11 Mar 2016 10:46:08 -0800 (PST)
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, RP_MATCHES_RCVD=-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 YXvopt5_w9vs for <mmusic@ietfa.amsl.com>; Fri, 11 Mar 2016 10:46:06 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C3C12DA4E for <mmusic@ietf.org>; Fri, 11 Mar 2016 10:46:06 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2BIk5TO088202 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <mmusic@ietf.org>; Fri, 11 Mar 2016 12:46:05 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: "mmusic@ietf.org" <mmusic@ietf.org>
References: <5636E9BC.5070902@nostrum.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <56E3126C.4020604@nostrum.com>
Date: Fri, 11 Mar 2016 12:46:04 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <5636E9BC.5070902@nostrum.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/ZI7p6IL6eu9FD0zHf5WkvKEPGuI>
Subject: [MMUSIC] RID Open Issue #3: Escaping in Extension Parameters
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 11 Mar 2016 18:46:08 -0000

I'm putting up the open issues in the RID draft that haven't had 
dedicated threads yet for a final round of discussion.

For this one, see 
https://tools.ietf.org/html/draft-ietf-mmusic-rid-04#section-10

    The constraints on an "a=rid:" line are extensible.  The syntax for
    these is:

    rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ]

    param-val         = *( %x20-58 / %x60-7E )
                        ; Any printable character except semicolon

    If an extension has values that can contain semicolons, they need an
    escaping mechanism.  Note that this is not an issue for any currently
    defined constraints, as they all take numeric values only.

    1.  Change extension syntax to only allow numeric values

    2.  Define a universal escaping mechanism for all extensions to use

    3.  Leave this problem for the first extension constraints - if any -
        to define value in a way that might allow a semicolon.  Note that
        this approach would allow the use of percent-style escaping
        (e.g., "%3B") but not backslash-style escaping (e.g., "\;"), as
        parsers that do not support the new constraint would interpret
        the embedded semicolon as a separator.

    PROPOSAL: Option #3


Previous discussion of this resulted in two comments: one agreeing with 
the proposal, and one which resulted in pointing out that 
backslash-style escaping cannot be employed if we choose this path.

If you disagree with the proposal, please send email in the next few 
days with an alternate proposal.

Thanks!

/a