Re: [sacm] Adam Roach's No Objection on draft-ietf-sacm-nea-swima-patnc-02: (with COMMENT)

[Ted Hardie <[e-mail]>]

If I may support Adam's comment on the URI question, I note some possible
confusion here:


On Wed, Feb 21, 2018 at 10:41 PM, Adam Roach <[e-mail]> wrote:

>
>
> §3.4.4:
> >  The location is expressed as a URI string consisting of a scheme and
> >  path.  [RFC3986] The location URI does not include an authority part.
> >  The URI schema describes the context of the described location.  For
> >  example, in most cases the location of the installed software product
> >  will be expressed in terms of its path in the filesystem.  For such
> >  locations, the location URI scheme MUST be "file" or the URI MUST
> >  appear without a scheme.  (I.e., "file" is default scheme.)  It is
> >  possible that other schemes could be used to represent other location
> >  contexts.  Apart from reserving the "file" scheme, this specification
> >  does not reserve schemes.  When representing software products in
> >  other location contexts, tools MUST be consistent in their use of
> >  schemes, but the exact string used in those schemes is not
> >  normatively defined here.
>

While a file URI without an authority section has a well-established
default (the localhost), there are many URI schemes for which "The location
URI does not include an authority part" would amount to a change in the
base syntax.  I believe this section needs to be rephrased to either
rephrase this such that file is the default scheme and "localhost" the
default authority or to provide a list of acceptable URI schemes and how
their syntax matches.

In general, it is useful for interoperability to have a limited set of
schemes; while some may be nonsensical (mailto in a location URI, for
example), there are many more corner cases like the data URI scheme that
may eventually cause interoperability failures.

regards,

Ted


>
> Please cite RFC 8098 in this paragraph.
>
> Saying that a URI can appear without a scheme is at least confusing and
> probably
> ambiguous. For example, I can't tell which of the following syntaxes are
> expected and/or allowed:
>
> 1. :///Applications/TurnipTwaddler
> 2. ///Applications/TurnipTwaddler
> 3. /Applications/TurnipTwaddler
>
> Read literally, the quoted paragraph describes the first. It probably
> means to
> describe the second (maybe?), but I suspect some implementors will
> interpret
> it as the third.
>
> This becomes even more problematic for Windows, where it might be
> interpreted
> to mean any of *four* things (where the final one is clearly wrong due to
> potential confusion between drive letters and URI schemes -- but which I'm
> sure will be implemented if not clearly spelled out):
>
> 1. :///C:/Program%20Files/TurnipTwaddler
> 2. ///C:/Program%20Files/TurnipTwaddler
> 3. /C:/Program%20Files/TurnipTwaddler
> 4. C:/Program%20Files/TurnipTwaddler
>
> To be clear, whatever you define in this document cannot allow the
> omission of a
> scheme to result in Form #4 above, as this is syntactically ambiguous.
>
> It also probably bears reiterating that omitting the "file" scheme from a
> URI
> doesn't exempt it from encoding according to RFC 8089 section 4 (e.g.,
> including an unescaped space, as in "Program Files", would be syntactically
> invalid).
>
> Finally, I question the assertion that "The location URI does not include
> an
> authority part." It's been a while since I used Windows on a regular
> basis, but
> my recollection is that files -- including applications -- can be accessed
> from
> a CIFS filesystem without associating a local mount point with them. It
> would be
> impossible to describe the location of such applications if the authority
> is
> required to be omitted. It is easy to anticipate that future iterations of,
> e.g., Linux may have similar properties. (Popular desktops already allow
> userland access of files on unmounted access using full URIs, which
> necessarily
> include authority components; it is not far-fetched to imagine that this
> functionality might be incorporated into the kernel at some point).
>
> ------------------------------------------------------------
> ---------------
>
> The following appears in several places:
>
> >  | Software       | A string containing the Software Locator value.  |
> >  | Locator        | This is expressed as a URI. This field value     |
> >  |                | MUST be normalized to Network Unicode format as  |
> >  |                | described in Section 3.4.4. This string MUST NOT |
> >  |                | be NULL terminated.                              |
>
> Section 3.4.4 doesn't describe the use of Network Unicode format, so this
> text
> is confusing. I'll note that file URIs are generally going to be percent
> encoded, so they shouldn't contain any non-ASCII characters. Section 4 of
> RFC
> 8089 deals with encoding considerations for file URIs. Other URIs have
> their own
> encoding considerations, and it would be somewhat ambitious for this
> document to
> take on any encoding specification above and beyond what is already
> defined for
> each scheme.
>
>
>