Paul:

I propose adding this information reference:

   [CBORDIAG] Bormann, C., "CBOR diagnostic utilities",
              <https://github.com/cabo/cbor-diag>.

Then, the text at the front of the examples would say:

   This appendix includes a set of examples that show the different
   features and message types that have been defined in this document.
   To make the examples easier to read, they are presented using the
   extended CBOR diagnostic notation (defined in [RFC8610]) rather than
   as a binary dump.

   The examples are presented using the CBOR's diagnostic notation.  A
   Ruby-based tool exists [CBORDIAG] that can convert between the
   diagnostic notation and binary.  The referenced webpage includes
   installation instructions.

   The diagnostic notation can be converted into binary files using the
   following command line:

   diag2cbor.rb < inputfile > outputfile

   The examples can be extracted from the XML version of this document
   via an XPath expression as all of the sourcecode is tagged with the
   attribute type="CBORdiag".  (Depending on the XPath evaluator one is
   using, it may be necessary to deal with &gt; as an entity.)

   //sourcecode[@type='CDDL']/text()

Does this resolve your DISCUSS position?

Russ


> On Sep 20, 2022, at 10:58 AM, Russ Housley <[email protected]> wrote:
> 
> Carsten:
> 
> Do you have a webpage anywhere that can be pointed to by this document?
> 
> Russ
> 
>> On Sep 8, 2022, at 8:36 PM, Paul Wouters <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> I am fine with a pointer to a downloadable source which can also contain the 
>> commands to install the software. Upon compromise, the pointer can be 
>> updated to protect the immutable RFC text. Wether it points to GitHub or 
>> IETF or elsewhere doesn’t matter to me.
>> 
>> Paul
>> 
>> Sent using a virtual keyboard on a phone
>> 
>>> On Sep 8, 2022, at 16:04, Russ Housley <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> 
>>> 
>>> 
>>>> On Sep 8, 2022, at 1:47 AM, Carsten Bormann <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> 
>>>> On 2022-09-08, at 04:14, Paul Wouters via Datatracker <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>>> 
>>>>> ----------------------------------------------------------------------
>>>>> DISCUSS:
>>>>> ----------------------------------------------------------------------
>>>>> 
>>>>>       gem install cbor-diag
>>>>> 
>>>>> I am concerned about adding install commands for "programs from the 
>>>>> internet"
>>>>> within an RFC. If the rubygem for some reason becomes malicious, we cannot
>>>>> pull it from the RFC (even if we pull it from the datatracker link, it 
>>>>> would
>>>>> still live on in copies of the RFC elsewhere and malicious people could 
>>>>> point
>>>>> to copies of those original RFCs to point people to downlod the malicious 
>>>>> rubygem.
>>>>> 
>>>>> I would be okay with an iet.org <http://iet.org/> download location of a 
>>>>> ruby gem.
>>>> 
>>>> “gem install” is the appropriate way to install rubygems software, not a 
>>>> “location of a rubygem”.
>>>> 
>>>> What you seem to be asking for is some indirection so we can swap out the 
>>>> name of the gem in case cbor-diag becomes rogue.  That does make some 
>>>> sense to me, but we’d need to install that indirection somewhere in a 
>>>> place maintained by the IETF.
>>>> 
>>>> ➔ “Please consult https://www.ietf.org/software/cbor-diag 
>>>> <https://www.ietf.org/software/cbor-diag> for the way to install this 
>>>> software”.
>>>> And that page would contain instructions including “gem install cbor-diag” 
>>>> until that goes rogue.
>>>> 
>>>> Can we get such a infrastructure of pages recommending software up and 
>>>> running?  Do we mire ourselves in process issues (who gets change control 
>>>> etc.)?
>>>> 
>>>> Data point from a quick search:
>>>> The RFCs that already suggest installing rubygems via a direct “gem 
>>>> install” include RFC 8152, RFC 8610, RFC 9052.
>>>> 
>>>> (In reality, I’d expect the rubygems organization to act more quickly on a 
>>>> report of cbor-diag going rogue than the IETF would.)
>>>> 
>>>> Grüße, Carsten
>>> 
>>> 
>>> Paul:
>>> 
>>> Are you satisfied with this explanation? Or, would you prefer the pointer 
>>> to https://www.ietf.org/software/cbor-diag 
>>> <https://www.ietf.org/software/cbor-diag>
>>> 
>>> Russ
>>> 
> 

_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to