Re: Question about pseudocode and <CODE BEGINS>

[Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>]

On 16-Dec-21 09:52, Joel M. Halpern wrote:
> The FAQ, which points to the code components list, is clear that the
> list is only about what is automatically considered code.  For that
> purpose, the list is comprehensive.  Anything not listed there is not
> considered code unless it is marked <code begin>...
>
> I am not sure what clarification you are asking for?

The FAQ is fine but the list does not explain itself.

OLD:
Code Components which may be found in IETF Contributions and IETF Documents:

NEW:
Non-exclusive list of Code Components which may be found in IETF Contributions and IETF Documents:

Regards
    Brian

> Yours,
> Joel
>
> On 12/15/2021 3:18 PM, Brian E Carpenter wrote:
> > Joel,
> > On 16-Dec-21 08:54, Joel M. Halpern wrote:
> > > The list is the list of things that will be considered to be code even
> > > if they are not marked.  As such, it is inherently complete.  
And  not
> > > limiting.
> >
> > Yes, but the list doesn't state that it's not limiting. IMHO that's a bug.
> >
> >      Brian
> >
> > > The trust complies with RFC 8721 section 4.3 in this regard.
> > >
> > > Yours,
> > > Joel
> > >
> > > On 12/15/2021 2:45 PM, Brian E Carpenter wrote:
> > > > On 16-Dec-21 07:44, John Levine wrote:
> > > > > It appears that Bob Hinden  <bob.hinden@xxxxxxxxx> said:
> > > > > > I agree, it not necessary to have a delimiter token.  Just say
> > > > > > something like:
> > > > > >
> > > > > >      A suggested algorithm in pseudo code for <foo> 
is as follows:
> > > > > > in the document.   It is essentially just text.
> > > > >
> > > > > I agree except for the "essentially".  It is just text.
> > > > >
> > > > > We went through a long process to decide what licenses to offer for
> > > > > RFCs and for
> > > > > computer code in them.  The TLP even describes what we consider to be
> > > > > code:
> > > > >
> > > > > https://trustee.ietf.org/documents/trust-legal-provisions/code-components-list-3/
> > > >
> > > > As has been pointed out off list, that list is incomplete, which would
> > > > be OK if it was stated to be non-exclusive, but it isn't.
> > > >
> > > > My original concern was different - if an implementer wants to borrow
> > > > from the pseudocode to make real code, they might be making a derivative
> > > > work from the RFC in a way that is not allowed by the Trust's legal
> > > > provisions**.
> > > >
> > > > As far as I know, we have never discussed this issue to see what the
> > > > community consensus might be.
> > > >
> > > > ** Before John says it, the author of the pseudocode is perfectly at
> > > > liberty to grant any license for it that they want, outside the IETF
> > > > standards process. But that's more work and may be tricky in a corporate
> > > > context.
> > > >
> > > > Regards
> > > >        Brian