Re: [Gen-art] Gen-ART review of 04 draft-ietf-appsawg-http-problem-01

Erik Wilde <erik.wilde@dret.net> Tue, 01 December 2015 08:30 UTC

Return-Path: <erik.wilde@dret.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A7B1A8BC1 for <gen-art@ietfa.amsl.com>; Tue, 1 Dec 2015 00:30:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.2
X-Spam-Level:
X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 1znMH6zfPS8p for <gen-art@ietfa.amsl.com>; Tue, 1 Dec 2015 00:30:37 -0800 (PST)
Received: from cm03fe.ist.berkeley.edu (cm03fe.ist.berkeley.edu [169.229.218.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23421A8BB5 for <gen-art@ietf.org>; Tue, 1 Dec 2015 00:30:36 -0800 (PST)
Received: from 46-126-159-4.dynamic.hispeed.ch ([46.126.159.4] helo=dretair11.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <erik.wilde@dret.net>) id 1a3gKY-0006L9-BL; Tue, 01 Dec 2015 00:30:36 -0800
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, General Area Review Team <gen-art@ietf.org>
References: <9904FB1B0159DA42B0B887B7FA8119CA6BEA9E49@AZ-FFEXMB04.global.avaya.com>
From: Erik Wilde <erik.wilde@dret.net>
Message-ID: <565D5AAB.2040109@dret.net>
Date: Tue, 1 Dec 2015 09:30:35 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BEA9E49@AZ-FFEXMB04.global.avaya.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/uPGLKNHex16zPi8ayBhyZ7ZiHYc>
Cc: "draft-ietf-appsawg-http-problem.all@tools.ietf.org" <draft-ietf-appsawg-http-problem.all@tools.ietf.org>
Subject: Re: [Gen-art] Gen-ART review of 04 draft-ietf-appsawg-http-problem-01
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2015 08:30:38 -0000

On 2015-11-30 14:31, Romascanu, Dan (Dan) wrote:
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
> Document: draft-ietf-appsawg-http-problem-01
> Reviewer:  Dan Romascanu
> Review Date: 11/30/15
> IETF LC End Date: 12/4/15
> IESG Telechat date:
> Summary: Ready (with one clarification question).
>
> Minor issues:
>
> One question which may be a matter of clarification rather than an issue:
>
> In Section 3:
>
> ØIf such additional members are defined, their names SHOULD start with a
> letter (ALPHA, as per [RFC5234]) and SHOULD consist of characters from
> ALPHA, DIGIT, and "_" (so that it can be serialized in formats other
> than JSON), and SHOULD be three characters or longer.
>
> What is the rationale here for the SHOULDs? What are the exception cases
> that require using SHOULD rather than MUST in this paragraph?

at least part of the reason was that the XML serialization would not be 
able to deal with names starting with numbers (because of XML's naming 
rules), and that this should be taken into account when using additional 
members.

on the other hand, the JSON serialization is meant to be the normative 
one, which means that this XML constraint should not mean that any JSON 
using legal JSON names for new members should be considered invalid, 
even if the names do not conform to XML's naming rules.

mark, am i recalling this correctly? thanks,

dret.

-- 
erik wilde | mailto:erik.wilde@dret.net |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |