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

[Kathleen Moriarty <[e-mail]>]

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



-- 

Best regards,
Kathleen