Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme

John C Klensin <john-ietf@jck.com> Wed, 11 May 2016 20:36 UTC

Return-Path: <john-ietf@jck.com>
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 9EF7412D0A3; Wed, 11 May 2016 13:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 ZmzPW-Y6AZ9M; Wed, 11 May 2016 13:36:19 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3481212D773; Wed, 11 May 2016 13:36:14 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1b0arP-000HM7-Cx; Wed, 11 May 2016 16:35:59 -0400
Date: Wed, 11 May 2016 16:35:54 -0400
From: John C Klensin <john-ietf@jck.com>
To: Ned Freed <ned.freed@mrochek.com>
Message-ID: <D5DEBFA22FBD50FCA0A22360@JcK-HP8200.jck.com>
In-Reply-To: <01Q01K03ULG000005M@mauve.mrochek.com>
References: <570D4C99.1030405@dcrocker.net> <CACweHND-OX+5okkJ+oE=6UN84x+CFtPBpMnU8HqaPbgQgJ_oWA@mail.gmail.com> <570E2510.4040408@ninebynine.org> <CACweHNCLS+QU2QveqYjkuPnDybbm-dtX9qQPsO4tTkgUoc5QYg@mail.gmail.com> <5710953E.5040505@gmx.de> <CACweHNDuDnP4P-4suUaFpS0OX-CbAYxn39jsZ3O_s-KYn=qbKw@mail.gmail.com> <a16b7cf5-3635-a3cb-b743-850f4047f862@gmx.de> <B3F27B33707E397A452D158D@JcK-HP8200.jck.com> <6f2915b6-d36b-fbf6-f8a5-e35cf646faeb@it.aoyama.ac.jp> <88F1BC9BE8337F5D3B95E1BA@JcK-HP8200.jck.com> <01Q01K03ULG000005M@mauve.mrochek.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/SQqmbKESsLuasNnfb2_O0LxFtSI>
Cc: Julian Reschke <julian.reschke@gmx.de>, draft-ietf-appsawg-file-scheme@ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 11 May 2016 20:36:23 -0000


--On Wednesday, May 11, 2016 07:27 -0700 Ned Freed
<ned.freed@mrochek.com> wrote:

>...
>> For some scripts, there are also what look from the outside
>> like internal consistency problems with Unicode: for example,
>> NFD is more internally consistent then NDC because many
>> recently-added precomposed characters decompose under NFC
>> rather than composing.  And some don't, leading to some of
>> the problems that led to the "non-decomposable character"
>> mess that led to the LUCID BOF and the IETF's apparent
>> paralysis about Unicode 7.x.
> 
>> It is hard to say something in cases like this that will
>> always deliver the best, or even the most-expected, results.
> 
> I'm trying, but I find it difficult to have much sympathy
> here. The underlying problem is that repeated applications of
> the "this is a tiny bit better for this constituency so we
> must have it or at least allow for it" rule in this space has
> led to a situation where no single best practice exists.
> 
> If this sounds like we've reached a distinctly suboptimal
> pareto optimum, it's because that's exactly what has happened.
> 
> I therefore think the best thing is to document the situation
> as best we can and be done with it. This is supposed to be a
> specification for a URL scheme; there's no reqruiement that
> such documents also serve as a BCP.

I hope it doesn't surprise you, but I agree.  Less is probably
more here, it is only the (IMO unnecessary) effort to be
exhaustive without either getting it right to the best of our
present knowledge or being clear that the guidance is general
only that I'm concerned about.

    john