Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-09.txt

Mark Nottingham <> Mon, 16 May 2016 07:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D79E912B019 for <>; Mon, 16 May 2016 00:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lLYXB3_kBTvP for <>; Mon, 16 May 2016 00:07:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C43412B00E for <>; Mon, 16 May 2016 00:07:10 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 56F6822E256; Mon, 16 May 2016 03:07:02 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Mon, 16 May 2016 17:06:59 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Matthew Kerwin <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: IETF Apps Discuss <>
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-09.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 May 2016 07:07:12 -0000

Hi Matthew,

I think the new Section 4 is an improvement -- much more precise than it was. However, a few questions still linger for me:

> 4.  File Name Encoding
>    File systems use various encoding schemes to store file and directory
>    names.  Many modern file systems encode file and directory names as
>    arbitrary sequences of octets,

This is a bit confusing -- perhaps s/encode/store/ ? Or remove this part of the sentence altogether?

>    in which case the representation as an
>    encoded string often depends on the user's localization settings, or
>    defaults to UTF-8 [STD63].
>    Without other encoding information, percent-encoded octets in a file
>    URI ([RFC3986], Section 2.1) MAY be interpreted according to the
>    preferred or configured encoding of the system on which the URI is
>    being interpreted.

Do the current implementations of file:// do this -- i.e., use the filesystem's encoding for the URI? 

Doing it that way seems unfortunate; two different users on the same machine (or network) won't see good interop in this approach.

If it's this way intentionally, or if we think it can't change, that's understandable, but if not we should have a good hard look at changing it IMO.

Has there been any discussion of this to date (sorry if I missed it)?


Mark Nottingham