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

From: Adam Roach <[email-masked]>
Date: Wed, 21 Feb 2018 22:41:11 -0800

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.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 22 Feb 2018 06:33:59 -0800

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

> >  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

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Tue, 27 Feb 2018 21:51:33 +0000

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:[email-masked]]
> Sent: Thursday, February 22, 2018 1:41 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; Karen
> O'Donoghue <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Adam Roach's No Objection on draft-ietf-sacm-nea-swima-patnc-02:
> (with COMMENT)
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 27 Feb 2018 16:55:48 -0500

Adam,

Please confirm if you agree your comments have been addressed.

Thank you!
Kathleen

On Tue, Feb 27, 2018 at 4:51 PM, Schmidt, Charles M.

-- 

Best regards,
Kathleen

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Tue, 27 Feb 2018 22:11:49 +0000

Hello,

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

Thanks,
Charles

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Thursday, February 22, 2018 9:34 AM
> To: Adam Roach <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; draft-ietf-sacm-nea-
> [email-masked]; Karen O'Donoghue <[email-masked]>;
> [email-masked]
> Subject: Re: Adam Roach's No Objection on draft-ietf-sacm-nea-swima-
> patnc-02: (with COMMENT)
> 
> On Wed, Feb 21, 2018 at 10:41 PM, Adam Roach <[email-masked]
> <mailto:[email-masked]> > wrote:
> 
> 
> 
> 
> 	§3.4.4:
> 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
> 
> 
> 
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 27 Feb 2018 18:19:48 -0600

Yes, the latest version addresses my concerns. Thanks to the authors for 
a rapid turn-around on these edits!

/a

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 27 Feb 2018 20:45:20 -0500

Thank you, all!

Sent from my mobile device

> On Feb 27, 2018, at 7:19 PM, Adam Roach <[email-masked]> wrote:
> 
> Yes, the latest version addresses my concerns. Thanks to the authors for a rapid turn-around on these edits!
> 
> /a
>