Subject: Re: #1175 Code vs text

From: John C Klensin <[email-masked]>
Date: Thu, 25 May 2006 10:07:09 -0400

Harald,

I think this is fine, except for the last provision and
something that seems to have been left out.

--On Thursday, 25 May, 2006 13:09 +0200 Harald Alvestrand
<[email-masked]> wrote:

> In our list of open issues, we have this issue:
> 
>> If there are different rights granted to participants for
>> working with  code than with non-code, it
>> has to be possible for users to tell which is which.
>>...
> There has been no discusssion with this issue number.
> Based on the in-room discussion in Dallas, I suggest that we
> resolve it by saying (remember, this is informing the IETF
> Trust about the desires of the IETF community):
> 
> If a distinction needs to be drawn between code and non-code
> in IETF documents, the community desires that:
> 
> - Specifications in formal languages, including C code, ABNF,
> MIBs, ASN.1 and so on, are clearly "code".
> - Tables such as the character lists in IDNA are to be
> regarded as "code" too.
> - Prose, including "pseudocode" that does not claim any level
> of formality, is not "code".
> - The IETF Trust should maintain specific guidance on what
> will be regarded as "code", including guidance on how to mark
> "code" in documents where doubt could exist; this guidance is
> expected to change more often than the IETF IPR rules.
> - If there is ever a conflict over what constitutes "code" in
> a document, the IETF Trust can make a decision on the issue.

If there is ever a _serious_ conflict over what constitutes
"code" in the above context, all that last statement does is to
make the IETF Trust party to the lawsuits.  I define "serious"
here as "willing to shed blood, even financial or other
metaphorical blood, over the issue".

I think you need to either 
	
	* stop after the bullet starting "The IETF Trust should
	maintain..."

or 

	* reopen the question of a "code" archive separate from
	the RFC text, if only as a way to force the "what is
	code" decision to be made when the document enters the
	RFC archive, rather that trying to sort things out
	retroactively.  

Of course, the second would probably require a modification to
the "TechSpec" document, so, if we were going to make that
decision, we had best make it quickly and feed the information
into the "Techspec" (i.e., draft-mankin-pub-req-08.txt) Last
Call.

> I think this communicates a desire of the community that it
> will be clear how to apply for the 95% case, and allows the
> IETF to decide on the borderline cases (if any) as we go along.
> 
> Comments?

At least absent the dreaded "copyright transfer idea" (which I
still don't favor, even though I keep bringing it up), I don't
think "as we go along" is likely to be viable in this area at an
acceptable level of pain and suffering for the reason outlined
above.   I think we need a mechanism for definitively knowing
what is code and what isn't at the time of publication.

The other issue, which ought to be orthogonal to this but
impacts it, is that I-Ds are different from published, archival,
RFCs.  Formally, I-Ds expire after six months and all rights,
except those covered by the Note Well, revert to the author.
Formally, we don't encourage production implementations from
I-Ds, so whether anyone needs lasting rights to "code" embedded
in I-Ds to fulfill any IETF purpose is an open question.  The
practices are a little different, but I hope we can get those
issues under control long before we have to sort them out of a
document at Last Call.

    john

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg