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

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

Hello,

Thanks a bunch for the feedback. I agree with your comments and believe they are addressed in the new (-03) draft.

Thank you,
Charles

> -----Original Message-----
> From: Adam Roach [mailto:[e-mail]]
> Sent: Thursday, February 22, 2018 1:41 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; Karen
> O'Donoghue <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> Subject: Adam Roach's No Objection on draft-ietf-sacm-nea-swima-patnc-02:
> (with COMMENT)
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-sacm-nea-swima-patnc-02: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swima-patnc/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for everyone's work on this document. I support Ben's DISCUSS, his
> concerns regarding the treatment of privacy in §8, and EKR's concerns
> regarding the phrasing "not generally considered to be sensitive."
> 
> I also have a few very important comments about this document's
> handling of URIs.
> 
> §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.
> 
> 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.
> 
>