Re: draft-reschke-rfc2231-in-http: section 4.2, Error Handling

Julian Reschke <julian.reschke@gmx.de> Mon, 01 March 2010 16:39 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDEAA28C2EC for <apps-discuss@core3.amsl.com>; Mon, 1 Mar 2010 08:39:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzBU44FG1FYv for <apps-discuss@core3.amsl.com>; Mon, 1 Mar 2010 08:39:31 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 841A03A879D for <apps-discuss@ietf.org>; Mon, 1 Mar 2010 08:39:30 -0800 (PST)
Received: (qmail invoked by alias); 01 Mar 2010 16:39:26 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.119]) [217.91.35.233] by mail.gmx.net (mp050) with SMTP; 01 Mar 2010 17:39:26 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19QAY4/NcdQ6ZZMlm5DRcMPQD87lp0RRndsDtx98Q WP64FKJ9Lk8lrw
Message-ID: <4B8BEDBB.9050807@gmx.de>
Date: Mon, 01 Mar 2010 17:39:23 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Thomas Roessler <tlr@w3.org>
Subject: Re: draft-reschke-rfc2231-in-http: section 4.2, Error Handling
References: <4c80fa21002241136y629dda22l1d7617eb25250af8@mail.gmail.com> <4B87F0FB.6090605@gmx.de> <4c80fa21002260942g3aacf02ak20510ca9d9c0659@mail.gmail.com>
In-Reply-To: <4c80fa21002260942g3aacf02ak20510ca9d9c0659@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.64000000000000001
Cc: apps-discuss@ietf.org
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Mar 2010 16:39:31 -0000

On 26.02.2010 18:42, Thomas Roessler wrote:
> On Fri, Feb 26, 2010 at 5:04 PM, Julian Reschke<julian.reschke@gmx.de>  wrote:
>
>>> Leaving the choice of precedence to the header specification implies
>>> that parsers need to special-case. It would seem reasonable to make a
>>> choice in this specification that for properties which can only occur
>>> once, the traditional syntax takes precedence.
>>
>> That would rule out the use case where the traditional syntax is used as a
>> fallback for clients that do not support the new syntax, as discussed in
>> that section:
>>
>> "Header specifications that include parameters should also specify whether
>> same-named parameters can occur multiple times. If repetitions are not
>> allowed (and this is believed to be the common case), the specification
>> should state whether regular or the extended syntax takes precedence. In the
>> latter case, this could be used by producers to use both formats without
>> breaking recipients that do not understand the syntax.
>
> That's a compelling argument for choosing "new style takes precedence"
> in the spec; I don't know of good arguments the other way.
>
> My main point is that I think we should make a choice (and either of
> the possible choices sounds reasonable), not which of the specific
> choices it should be.

Ok, let's make that choice, this would result in:

    Header specifications that include parameters should also specify
    whether same-named parameters can occur multiple times.  If
    repetitions are not allowed (and this is believed to be the common
    case), the specification should state that the extended syntax takes
    precedence.  This could be used by producers to use both formats
    without breaking recipients that do not understand the syntax.

However, that would still only be a recommendation -- so if a header 
definition deviated from that, a generic processor wouldn't be usable 
(or return the wrong choice).

Would that be ok, or are we prepared to mandate a choice here?

Best regards, Julian