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

[Adam Roach <[e-mail]>]

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.