Re: [sacm] WGLC for draft-ietf-sacm-coswid

[Ira McDonald <[e-mail]>]

Hi Dave,

To Alex's point about UTF-8 usage, I recommend requiring conformance to
RFC 5198 Unicode Format for Network Interchange, to remove ambiguity
and ensure normalization of text.

Cheers,
- Ira



Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [e-mail]
PO Box 221  Grand Marais, MI 49839  906-494-2434



On Wed, Jul 3, 2019 at 1:33 PM Waltermire, David A. (Fed) <david.waltermire=
[e-mail]> wrote:

> Thanks for the feedback Alex. I’ll fix these issue at the end of the WGLC
> along with any other comments that come up.
>
>
>
> Regards,
>
> Dave
>
>
>
> *From:* sacm <[e-mail]> *On Behalf Of * Nelson, Alexander J.
> (Fed)
> *Sent:* Wednesday, July 3, 2019 1:07 PM
> *To:* [e-mail]
> *Subject:* Re: [sacm] WGLC for draft-ietf-sacm-coswid
>
>
>
> Hello all,
>
>
>
> I am a colleague of Dave's, and am working at NIST to assist with SWID
> adoption.  I have reviewed this draft for CoSWID, and found a few helpful
> notes for my own implementation efforts, so I am glad to have been asked
> for input.
>
>
>
> I find this draft to be nearly ready for publication..  There are a few
> minor editorial issues that should be resolved before publication, listed
> at the end of this message.  I also found I had a few questions and
> possible discrepancy identifications, listed first.
>
>
>
>
>
> Questions:
>
>
>
> * Before I started reading the document, I thought that CoSWID would be a
> losslessly-translatable representation of SWID data, between XML and CBOR.
> From Section 2's third paragraph, this is stated to not be a goal feature.
>  (In case it isn't clear, I don't object to this.)  Is it at least possible
> to translate from one format to the other, not necessarily bilaterally, and
> perhaps under certain conditions like "if there are no extension elements
> or attributes, SWID XML can be mechanically translated to CoSWID"?  From my
> reading, it looks like that example statement I just wrote would hold.
>
>
>
> * Section 2.2, the "software-name (index 1)" text describes what I think
> is the first potential spot for non-ASCII text to be entered into CoSWID
> data, in the case of vendors that produce non-English data.  I didn't see
> in this document any requirements imposed for character encodings.  SWID
> imposes UTF-8 as an encoding (per NISTIR 8060, Section 4.3).  Could this
> document include a reminder statement on character encodings being required
> to be UTF-8?
>
>   - This might also apply in Section 5.2.1, the penultimate bullet
> describing registered names' syntax requirements.
>
>
>
> * Section 6's 2nd paragraph describes a requirement of authoritative tags
> being signed by the software provider that is also the originator.  Forgive
> me if I'm misremembering, but I did not think that signing was a
> requirement for defining a tag to be authoritative.  NISTIR 8060, Section
> 3.2, quotes the SWID specification's Section 6.1.10 to say that "Signatures
> are not a mandatory part of the software identification standard...".
> Further, NISTIR 8060, Section 4.2, provides a scoped-to-that-document
> definition of "authoritative tag creator" that does not describe signing.
> So, it looks to me like Section 6 imposes a stronger requirement for an
> "authoritative" CoSWID tag than an XML-based SWID tag.
>
>
>
>
>
> Editorial issues:
>
>
>
> * Section 1 makes reference to "CBOR," but the first instance of the
> acronym expansion and citation is in the first sentence of Section 1.2.  It
> may be better to move that expansion and citation to Section 1.
>
>
>
> * Figure 1's "x" annotations aren't directly explained, and could be
> interpreted to mean removal of the tag at that stage.  From the following
> bulleted narrative, it instead appears to mean the tag can be removed or
> replaced.  A sentence in the figure's caption would help to prevent this
> conclusion.  Though, if the reader is assumed to have the patience to wait
> for a page, then there's no problem.
>
>
>
> * Suggested grammar fix, section 2:
>
>
>
>     s/and stop point are not needed saving bytes/and stop point are not
> needed, saving bytes/
>
>
>
> * Request for grammar adjustment, Section 2.1:  """... that are typically
> stored in the "any attribute" of an ISO-19770-2:2015 in XML
> representation."""  Does this need the following substitution?
>
>
>
>     s/2015 in XML/2015 element in XML/
>
>
>
> * Section 2.2, I'm curious - what happened to the mapping of 7?  No
> editorial action needed, the skip just caught my eye.
>
>
>
> * Section 2.2, typo: "The value of an version-scheme ...."
>
>
>
> * Section 2.2, typesetting error: The three bullets following "The value
> of an version-scheme item MUST be one of the following" appear to be set at
> an incorrect bullet level.  Elsewhere in the document, these sub-lists use
> asterisks as bullets instead of empty circles.  It appears these three
> bullets should be asterisks, not empty circles.
>
>
>
> * Section 2.3, bullet 2 ("""If the patch item is set to "true", the tag
> SHOULD..."""): Would it be beneficial here to note the associated schemes
> for link hrefs?  This could be a forward reference to Section 2.6.
>
>
>
> * Section 2.7, bullet "description (index 46)": Is it permitted to have a
> description be multiple lines?  I don't know if CBOR supports this.
>
>
>
> * Section 2.7, typo: "For examplem, this ..."
>
>
>
> * Section 2.7, bullet "unspsc-code":  Non-blocking issue, a matter of web
> reference hygiene.  May this URL be provided with the "https" protocol
> instead of the "http" protocol?  (Bibliography entries refer to web
> resources with the "https" protocol.)
>
>
>
> * Section 2.8.8, bullet "path-elements (index 26)", typo: "a heirarchy".
>
>
>
> * Table 3, typo: "e.g.,1.2.3, ..." (missing space character)
>
>
>
> * Section 5.2.1, typo: "a new a new"
>
>
>
> * Section 6, paragraph 2: It may be beneficial to provide a reference to
> RFC 8152 near the mention of signing CoSWID tags.
>
>
>
>
>
> --Alex
>
>
>
>
>
> On Jun 27, 2019, at 4:36 PM, Karen O'Donoghue <[e-mail]> wrote:
>
>
>
> Folks,
>
>
>
> As discussed at our virtual interim on Tuesday, this begins a three week
> working group last call for:
>
>
>
> Concise Software Identification Tags
>
> https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/
> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sacm-coswid%2F&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C91c6b28941ce4a772c3c08d6ffd8f9e3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636977704712452256&sdata=PAS8N3br%2FthOhPonKJzuWUlIsn9bQvqSZ%2F6hbE3%2FhDU%3D&reserved=0>
>
>
>
> Please reply to this email thread with an indication that you have read
> the document, any comments you may have, and your assessment of whether or
> not it is ready to proceed to publication.
>
>
>
> DEADLINE: Please reply by Friday 19 July 2019.
>
>
>
> Thanks!
>
> Karen and Chris
>
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
>
>
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
>