Re: [apps-discuss] Experimental (was - Re: Review of draft-ietf-appsawg-file-scheme)

I'm not sure if this will help, or just add more noise, but...

TL;DR:  I don't think the "over the wire" issue should be elevated to the level 
of dogma.  Systems are more complicated than that.

...

For me, as a developer, the value of a file:// URI is not what gets sent "over 
the wire", but what does *not* get sent over the wire.

I mainly work on applications for "small data" (but very heterogeneous). I 
create data that can be served on the web, or locally from a file system.  The 
data itself is location agnostic (i.e. portable), and internally uses relative 
URI references.  The existence of file: URIs is important to this mechanism 
because they can be used locally as a base URI to access data that is stored 
locally.

So why do I feel the file: is an important specification that impacts 
interoperability in a network protocol suite?

1. it can be used uniformly as part of a structure that does operate 
predominantly over the network.

2. It can be used to provide a local context for interpreting data that *has* 
been sent "over the wire".

This is why I have said that (for me at least), the most important part of the 
file: URI spec is that it behaves consistently with respect to URI resolution.

#g
--

On 14/04/2016 06:35, Mark Nottingham wrote:
> What do you consider "the wire" for the purposes of the file:// URL scheme?
>
>
>> On 14 Apr 2016, at 1:06 PM, Dave Crocker <dhc2@dcrocker.net> wrote:
>>
>> On 4/13/2016 7:55 PM, Matthew Kerwin wrote:
>>>     This is why focusing on bits over the wire is better than talking
>>>     about software implementation details.  If the 'different ways' mean
>>>     different bits over the wire, then they are using different formats
>>>     or different protocols.  And they won't interoperate.
>>>
>>>     If they generate/parse the same bits and same semantics over the
>>>     wire, this we don't care how the built the software to do it,
>>>     because they /do/ interoperate.
>>>
>>>
>>> The 'different ways' are actually different bits over the wire. Mostly
>>> those are the bits that weren't part of the original spec, but were
>>> widely deemed useful/necessary. I've tried to sidestep too much
>>> controversy by continuing not to specify them, but I did write down some
>>> of the ways some folk have decided to represent them.
>>
>>
>> OK.  My advice:
>>
>>      If there is a common core of bits over the wire that they all do do, but then some /additional/ bits over the wire that are different, then write the spec for the common parts and note (but do not document) that there are various independent extensions.
>>
>>      Treat any effort to document the variations as completely separate from the common core.
>>
>>
>> d/
>>
>> --
>>
>>   Dave Crocker
>>   Brandenburg InternetWorking
>>   bbiw.net
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>