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

Graham Klyne <> Wed, 13 April 2016 10:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3069212E4B4; Wed, 13 Apr 2016 03:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bgvo9kaQ2GhC; Wed, 13 Apr 2016 03:35:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5A4D12E4B0; Wed, 13 Apr 2016 03:35:05 -0700 (PDT)
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1aqI8T-0000pq-oG; Wed, 13 Apr 2016 11:35:01 +0100
Received: from ([] helo=[]) by with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1aqI8T-0004Kt-E6; Wed, 13 Apr 2016 11:35:01 +0100
Message-ID: <>
Date: Wed, 13 Apr 2016 11:34:59 +0100
From: Graham Klyne <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Matthew Kerwin <>, Dave Crocker <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: <>
Cc:, Apps Discuss <>
Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme
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: Wed, 13 Apr 2016 10:35:14 -0000

On 13/04/2016 09:28, Matthew Kerwin wrote:
>> >
>> >In technical terms, document seems to suffer some confusion about its role
>> >as a format specification, versus as a protocol specification.  I believe
>> >this issue is basic and important.  It needs to be resolved.
>> >
>> >
> I don't disagree. Guidance on how to clarify this would be appreciated. How
> many URI specs don't also define a protocol? If this is the only one, then
> I probably don't know how to set the precedent. (Some of this is sorted
> below, with your suggestions.)

A URI is a structured data element used in protocols (e.g. HTTP) and in data 
formats (e.g. HTML).  As such, I don't think it makes sense to call it a "protocol".

The expected interpretation of some URI schemes will depend on a protocol 
specification (e.g. HTTP), and its definition may appear in the protocol spec. 
E.g., but the URI itself is a 
string that conforms to indicated syntax that can be used predictably with 
common URI handling operations such as resolution 

As for other URI specs that don't define a protocol...


(That's from a very brief look at