Subject: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Dec 2014 08:37:34 -0800

This opens a call for adoption for draft-kerwin-file-scheme, to be
processed by APPSAWG.  There appears to be enough interest in the work
given the feedback it's getting, and it appears to fit within our charter.

Please indicate your support or objection by replying to this thread.  The
call will close on January 9, 2015.

-MSK, APPSAWG co-chair

---

From: t.petch <[email-masked]>
Date: Wed, 17 Dec 2014 16:52:32 +0000

I support adoption

Tom Petch

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: "IETF Apps Discuss" <[email-masked]>
Sent: Wednesday, December 17, 2014 4:37 PM

> call will close on January 9, 2015.

------------------------------------------------------------------------
--------

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Dec 2014 10:56:59 -0600

> call will close on January 9, 2015.

I'm in favor.

---

From: Sean Leonard <[email-masked]>
Date: Wed, 17 Dec 2014 10:57:50 -0800

On 12/17/2014 8:37 AM, Murray S. Kucherawy wrote:
> processed by APPSAWG.

I support adoption.

Sean

---

From: Ira McDonald <[email-masked]>
Date: Wed, 17 Dec 2014 15:29:56 -0500

Hi,

I'm in favor of adoption of this document as an AppsAWG work item.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

---

From: Sam Ruby <[email-masked]>
Date: Wed, 17 Dec 2014 20:23:13 -0500

On 12/17/2014 11:37 AM, Murray S. Kucherawy wrote:
> Please indicate your support or objection by replying to this thread.
> The call will close on January 9, 2015.

This is NOT an objection, but I will note that draft-kerwin-file-scheme 
makes a reference to a document I co-edit:

https://tools.ietf.org/html/draft-kerwin-file-scheme-13#ref-WHATWG-URL

I further would like APPSAWG to consider the following as input:

http://tools.ietf.org/html/draft-ruby-url-problem-00

- Sam Ruby

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 18 Dec 2014 12:01:52 +1000

> http://tools.ietf.org/html/draft-ruby-url-problem-00
​Yes, the more this can tie in with other efforts (notably​ in the W3C and
WHATWG) the better. If draft-ruby-url-problem eventually ends up with a BCP
we'll definitely do all we can to adhere to it, and even without, I think
the principle is worthy and we'll strive anyway. If that involves a
reference to a new informational RFC, all well and good.

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: t.petch <[email-masked]>
Date: Thu, 18 Dec 2014 10:16:47 +0000

----- Original Message -----
From: "Sam Ruby" <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cc: <[email-masked]>; "Larry Masinter" <[email-masked]>
Sent: Thursday, December 18, 2014 1:23 AM
> https://tools.ietf.org/html/draft-kerwin-file-scheme-13#ref-WHATWG-URL

True, it does, but as in Informational Reference as part of the history
of the file: scheme.  As such, it could easily be removed with no loss
to the Normative part of this specification.

I have read WHATWG-URL and do not think that it contributes to the
objectives of draft-kerwin-file-scheme and so while I am fine with
keeping the reference in, I do not think that it should be a factor in
the discussions of
draft-kerwin-file-scheme.

Tom Petch

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 18 Dec 2014 09:06:27 -0500

> call will close on January 9, 2015.

In its current form, the draft has normative references to two non-IETF 
documents that don't have clear licensing terms, specifically MS-DTYP and MS-
NBTE.  As nearly as I can determine, these are not covered by the Microsoft 
Open Specification Promise [1].  Given that these are normative references, I 
think it's essential that their IPR status be clear.  I don't think it's 
appropriate on something as fundamental as the file URI scheme to end up with a 
document that's IPR constrained.

Before this document is accepted, it should either be reworked to no require 
these as normative references or the IPR status of the references should be 
clarified to make it clear that their use is not encumbered (adding them to the 
OSP would be a great way to do this).

Scott K

[1] http://www.microsoft.com/openspecifications/en/us/programs/osp/default.aspx

---

From: Sam Ruby <[email-masked]>
Date: Fri, 19 Dec 2014 19:45:35 -0500

On 12/17/2014 09:01 PM, Matthew Kerwin wrote:
> On 18 December 2014 at 11:23, Sam Ruby <[email-masked]
> <mailto:[email-masked]>>wrote:
>
>     This is NOT an objection, but I will note that
>     draft-kerwin-file-scheme makes a reference to a document I co-edit:
>
>     https://tools.ietf.org/html/__draft-kerwin-file-scheme-13#__ref-WHATWG-URL
>     <https://tools.ietf.org/html/draft-kerwin-file-scheme-13#ref-WHATWG-URL>
>
>     http://tools.ietf.org/html/__draft-ruby-url-problem-00
>     <http://tools.ietf.org/html/draft-ruby-url-problem-00>
>
> ​Yes, the more this can tie in with other efforts (notably​ in the W3C
> and WHATWG) the better. If draft-ruby-url-problem eventually ends up
> with a BCP we'll definitely do all we can to adhere to it, and even
> without, I think the principle is worthy and we'll strive anyway. If
> that involves a reference to a new informational RFC, all well and good.

Thanks!

I'm sure that we can learn much from each other, and the specs we 
produce will benefit as a result.

To start off, I'd like point out one area where there may be some 
technical issues that you might not be aware of -- and I encourage you 
to do the same with specs I am working on.

So as to not affect the call for adoption, I've changed the subject line.

The area I've chosen to focus on first is host names -- something that 
is particularly thorny.  The RFCs you reference don't quite capture all 
of the necessary behavior.  I encourage you to explore the following 
URIs.  In particular, I recommend exploring these with the Chrome browser:

file://2130706433/foo
file://[2001::1]/foo
file://０Ｘｃ０．０２５０．０１/foo

Note that the last one is using Unicode wide characters.  An alternate 
representation would be as follows:

file://\uFF10\uFF38\uFF43\uFF10\uFF0E\uFF10\uFF12\uFF15\uFF10\uFF0E\uFF10\uFF11/foo

You may find the following online tool to be handy for exploring cases 
such as these:

https://url.spec.whatwg.org/reference-implementation/liveview.html

- Sam Ruby

---

From: Larry Masinter <[email-masked]>
Date: Sat, 20 Dec 2014 19:55:30 +0000

> This opens a call for adoption for draft-kerwin-file-scheme, to be processed by APPSAWG.  

I don't think apps area should take up kerwin-file-scheme as an independent work item, not because the work isn't important but because apps-discuss is too congested to manage the discussion (no responses to my Dec 9 comments https://www.ietf.org/mail-archive/web/apps-discuss/current/msg13462.html ). In general, APPSAWG shouldn't take up URL-scheme permanent registrations? Or should it? This should be addressed in the scheme registration BCP.

Larry
--
http://larry.masinter.net

---

From: Sean Leonard <[email-masked]>
Date: Sat, 20 Dec 2014 14:09:07 -0800

> OSP would be a great way to do this).

This is probably a good non-technical example of why I advocated for the 
"local convention" from a technical standpoint (see

http://mailarchive.ietf.org/arch/msg/apps-discuss/k80c33MWSWC2lxdGq0YmcrJi5Uw  ; also echoed in Larry Masinter's second comment http://mailarchive.ietf.org/arch/msg/apps-discuss/NsOYamN15GcMrSV1bBuOrA5XirY).

file: should be seen as an "escape hatch" for the (majority of) the string to be processed by an OS-specific filesystem API, with no more than rudimentary interpolation.

Documenting these operating-specific behaviors is all well and good, but passing normative statements on OS vendors for their own software will not get what you want or change the behaviors of these APIs/products. The best thing is to say "look to the [OS vendor] documentation for [normative guidance] on how this is constructed".

To pick a non-Microsoft example, consider Apple Mac OS X's handling of file URLs:
https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/AccessingFilesandDirectories/AccessingFilesandDirectories.html

The premise that normative documentation by one OS vendor (e.g., Microsoft) is required to interpret file: for that OS, should not be a barrier to the file: scheme in general or to an RFC in particular. The right way to deal with that is to write the RFC in such a way that OS-specific variations are not required for RFC-compliance in the first place. If you want to write a Linux tool that interprets Microsoft Windows file: URLs, #1 - why bother? it's not usable; #2 - as the tool author, shouldn't you be looking at Microsoft's documentation anyway, regardless of its licensing terms? You want compatibility with actual Windows software, not with some arbitrary RFC.

-Sean

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 1 Jan 2015 14:51:00 +1000

On 21 December 2014 at 05:55, Larry Masinter <[email-masked]> wrote:

> I don't think apps area should take up kerwin-file-scheme as an
> independent work item, not because the work isn't important but because
> apps-discuss is too congested to manage the discussion (no responses to my
> Dec 9 comments
> https://www.ietf.org/mail-archive/web/apps-discuss/current/msg13462.html
> ). In general, APPSAWG shouldn't take up URL-scheme permanent
> registrations? Or should it? This should be addressed in the scheme
> registration BCP.
>
>
Sorry for not responding sooner, I've been a bit overwhelmed with real
life, and there's quite a back-log of comments and messages to aggregate
and process.

Regarding adoption of URL schemes by this WG, what alternatives would you
propose? I could instead try to make it an individual submission, but this
particular scheme has a lot of political and emotional history, and there
seems to be more and more work involved with developing the spec, so I'd
rather have much more buy-in through the whole process (such as you get
from a working group). I don't think it's big enough to warrant spinning up
its own WG, and I'm not aware of any others that would be more appropriate
than here.

​Cheers

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Dec 2014 22:37:06 -0800

> its own WG, and I'm not aware of any others that would be more appropriate

The BCP for registering schemes appears not to require an RFC, only Expert
Review.

The guideline I've had in mind both for schemes and media types is this: If
there's a lot of development work to be done on the format of what's to be
registered, or if Standards Track status seems to be worthwhile or even
necessary, then a working group (this one or a new one) makes sense.  On
the other hand, if it's mostly just documenting and then registering
something already quite well understood, I think the independent stream is
worth considering.  Even better: If the required documentation could simply
be included in the registration template, then just do that, and then
there's no need to produce an RFC through any stream.

An individual submission requires AD sponsorship, and I don't think this
has been shopped to any ADs yet (has it?).

All that said, one of the earlier threads about this work certainly made me
think there's a non-trivial number of issues that need attention before
this one could be done right, so working group attention (this or a new
one) is warranted.  If we want to spin off a WG for it, that's for Barry to
consider (anyone feel like writing a charter?).

All THAT said, Larry's earlier message (URI cited above) does still need a
reply, I believe.  If this draft does get adopted, that will be necessary
before we can progress the document.

-MSK