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

[Adam Roach <[e-mail]>]

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

/a

On 2/27/18 3:55 PM, Kathleen Moriarty wrote:
> 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.
> <[e-mail]> wrote:
>> 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.
>>>
>>>
>
>