Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset

Julian Reschke <julian.reschke@gmx.de> Wed, 18 April 2012 18:26 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275DC21F84CD for <apps-discuss@ietfa.amsl.com>; Wed, 18 Apr 2012 11:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.923
X-Spam-Level:
X-Spam-Status: No, score=-102.923 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0g2s6oKiFyTi for <apps-discuss@ietfa.amsl.com>; Wed, 18 Apr 2012 11:26:48 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E366F21F8476 for <apps-discuss@ietf.org>; Wed, 18 Apr 2012 11:26:44 -0700 (PDT)
Received: (qmail invoked by alias); 18 Apr 2012 18:26:43 -0000
Received: from p57A6F50E.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.245.14] by mail.gmx.net (mp038) with SMTP; 18 Apr 2012 20:26:43 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/od4pb3hToC/rVCacCzuPS7LQgO7DvhFvVXb09aT kJRNuvMLL4YAQ/
Message-ID: <4F8F0762.3010509@gmx.de>
Date: Wed, 18 Apr 2012 20:26:42 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> <D7569D7B-F1C9-45B6-8066-6BC8149B00E4@tzi.org> <4F83EF76.3000703@gmx.de> <A3733EB7-9BBB-4A9F-A1CE-6CFEC0FADDB8@tzi.org>
In-Reply-To: <A3733EB7-9BBB-4A9F-A1CE-6CFEC0FADDB8@tzi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 18 Apr 2012 18:26:51 -0000

On 2012-04-10 10:54, Carsten Bormann wrote:
> On Apr 10, 2012, at 10:29, Julian Reschke wrote:
>
>> On 2012-04-09 18:57, Carsten Bormann wrote:
>>> * Technical summary
>>>
>>> This is the right thing to do, and should have been done right after the end of the UTF wars.
>>>
>>> * Editorial issues
>>>
>>> The document appears to spell out a SHOULD for "text/html" and "text/xml".
>>> Does it change the meaning of text/html and text/xml?
>>
>> No. But it licenses future revisions of these specs to do the right thing.
>>
>>> Reading more closely, this apparently isn't meant, but there is a potential misunderstanding.
>>
>> We tried to clarify this in the latest draft. Can you suggest changes?
>
> (such as "text/html" and "text/xml")
> ->
> (such as "text/html" and "text/xml" are able to)

Done.

> And in the start of that paragraph:
>
> registrations
> ->
> future registrations

Not convinced. This document changes the rules; I think it's pretty 
clear that it doesn't apply to past registrations.

>>> More generally:
>>> When looking at a random media type three years from now, how do I find out whether this sentence does apply:
>>>     It does not change the
>>>     defaults for any currently registered media type.
>>
>> The media type definition will have to state the default.
>
> Yes.
>
> s/currently//
>
> Again. maybe

Again not convinced.

> for text/* media types
> ->
> for future registrations of text/* media types
>
> in the same paragraph.

See above :-)

>>> Even more generally:
>>> Who is affected by (needs to read) this specification?
>>> Who are the targets of the SHOULDs and MUSTs?
>>> How do I find out whether an implementation complies?  interoperates?
>>
>> The audience is people registering media types.
>>
>> And yes, one could argue this spec needs to RFC2119 keywords.
>
> I can't parse that last sentence.
>
> The MUST and the MUST NOT at the end of 3 are clearly meta-specs, and not for registrations either, but for "protocols".
> They generate a conflict for existing specs such as RFC 2616 without indication how to resolve that conflict.
> I know (the draft is mute about that) that we are fixing 2616, but this draft says nothing about how to handle that kind of conflict.
>
> Again, adding little words such as "future" might help.
> Or maybe the indication that these existing conflicting protocols are unbearable and will all need to be fixed (!?).

That's a good question.

As we already fixed it in HTTP, is there anything else we need to worry 
about`?

>>> And meta^3:
>>> What is the IETF name for specifications that are exclusively intended to remind us not to make a certain class of mistake again when generating future specifications?  Which specification wins when such a meta-specification is neglected in a specific specification?
>>
>> This document updates RFC 2046, I don't think more needs to be done here...
>
> I'm fine with that, I'm just not fine with the ambiguity resulting from retroactively changing meta-specs that have conflicting specs in force.
> I think with the above clarifications in place we might be reaching the point of diminishing returns in managing this specific conflict.
> I'm just trying to make the more general point here that you have to be careful in how you rewrite history.
>
> Grüße, Carsten

Best regards, Julian