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

["Schmidt, Charles M." <[e-mail]>]

Hello,

Thank you for the comments. I agree and believe that the new (-03) version will address your comments.

Thanks,
Charles

> -----Original Message-----
> From: Ted Hardie [mailto:[e-mail]]
> Sent: Thursday, February 22, 2018 9:34 AM
> To: Adam Roach <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; draft-ietf-sacm-nea-
> [e-mail]; Karen O'Donoghue <[e-mail]>;
> [e-mail]
> Subject: Re: Adam Roach's No Objection on draft-ietf-sacm-nea-swima-
> patnc-02: (with COMMENT)
> 
> 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]
> <mailto:[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.
> 
> 
> 
>