Subject: issue tracker created for IPR wg

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 20 Jan 2006 21:09:39 -0500

To help keep track of open issues, we've created an issue tracker.  To 
see the open issues, go to

	https://rt.psg.com/Search/Results.html?Query=Queue = 'ipr' AND (Status = 'open' OR Status = 'new')&Rows=50

or go to https://rt.psg.com and click on 'ipr'.  In either event, you 
have to log in with login ietf, password ietf.  You'll also have to 
accept the certificate for that site; that the only risk in doing 
so is if someone is spoofing that site for the purpose of capturing 
your publicly-known password...  Also note that all access is via 
https, not http.

The initial four issues were taken from the status report that Harald 
posted a few days ago.  If you have an issue you want the WG to 
consider, please email me (ccing the WG if you wish) and state 
explicitly the title and text of the issue.  Please make each issue as 
narrow as possible -- if your concern is that is that RFC with patent 
issues should be printed in red, those with trademark issues in blue, 
and those with both in purple, please submit that as three separate 
requests.

At least for now, I will add all non-duplicate issues to the tracker.  
Harald and I will then try to conduct focused discussions on each 
issue; we'll try to update the tracker with salient comments or 
developments.  (When discussing an issue, please include the issue 
number in the email subject line.)

It does take a little while for everyone to get the hang of how to use 
an issue tracker.  Please bear with us while we get this organized.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

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

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 21 Jan 2006 06:51:31 +0100

That is a very useful tool, thanks!

Since you are -- based on the titles of existing tickets -- continuing
down the code vs text approach, I believe one ticket ought to be to
define what "code" and "text" means.

I'm not sure it is possible to get consensus on an exhaustive list of
what "code" is.

One workable solution may be to let RFC authors specify the
separation, possibly helped by some discussion and examples of what
may definitely be counted as code (e.g., ASN.1 schemas).

A related item will then be how authors should mark code-portions and
text-portions in submissions.

For the record, I continue to believe that separating the license
discussion for code and text is premature.  I'm not opposed to the
idea, but there are problems in adopting that approach which we
haven't touched on yet:

 1) It forces us to define the difference between "code" and "text".
    That is difficult, and just started.

 2) It may force RFC editors to learn about this distinction, and
    perhaps to properly mark portions of their contributions.  That
    will be a major hassle for RFC authors.  I'm not convinced all RFC
    authors understand this issue, nor am I convinced there is any
    point in them being educated about it.  Let technical people focus
    on technical work, that's what they do best.  The IPR situation
    will be even less liked by IETF contributors if they need to
    bother themselves with it even further.  If there was just one
    license for all of the document, this would be less of a concern.
    I think the implications outlined here are poorly understood.

 3) If the text-license issue is stalled (which I anticipate it will,
    if focus is shifted to the code-license), the problems that
    initiated my effort in this area -- my own, Debian and FreeBSD's
    -- will not be addressed.  Thus, the results in this area will be
    "much ado nothing".

 4) Splitting this issue now may partially or completely destroy an
    interesting discussion on the principles the IETF should adopt for
    its copying conditions.

Thanks,
Simon

---

From: "todd glassey" <[email-masked]>
Date: Fri, 20 Jan 2006 23:20:14 -0800

Simon,  Steven, WG...

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "Steven M. Bellovin" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 20, 2006 9:51 PM
Subject: Re: issue tracker created for IPR wg

> I'm not sure it is possible to get consensus on an exhaustive list of

I am not sure we need concensus on what "it" is, just on how to include it
into the documents...

Lets perhaps change the focus of this argument to be one on how to include
the code rather than forcing all the myriads of types of code to be defined
here... i.e.  what if there were a specific part of the I-D or RFC that
contained 'text that was specified to be code' or alternatively was some
specific rule to embedding code into a RFC or I-D like 'its encapsulated in
a frame or is footnoted as code' - that is a simple rev on the I-D and RFC
templates or construction rules...

t.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 21 Jan 2006 07:44:59 -0600

(changing the subject line, since we are discussing an issue, not the issue 
tracker)

Hi, Simon,

> define what "code" and "text" means.

I agree, or at least I agree that we need to define how anyone would know 
what is permitted with any particular portion of an RFC, if different uses 
are permitted with different portions of an RFC.

> I'm not sure it is possible to get consensus on an exhaustive list of

Even if we are able to do this now, new ways of using portions of an RFC may 
arise at some point in the future. I'm not sure that twenty years ago we 
would have recognized as code all of what we now see as code, and people may 
come up with ways of using a portion of an RFC as code that we don't know 
about now.

To give a poorly-thought-out example, we seem to like letting people use 
MIBs from our documents, because they can be fed into compilers; if we 
started publishing RFCs in XML2RFC form at some point, I'm not sure how we 
would explain "well, if you feed THIS part of the ASCII data into THIS 
program, that's allowed, but if you feed ALL of it into SOME OTHER program, 
that's not allowed" to anyone outside the IETF, much less to a jury.

But please don't critique this poorly-thought-out example unless you are 
arguing that we will never figure out new ways to use portions of RFCs, 
beyond the pragmatic lists of "types of code" that we've been discussing so 
far.

> may definitely be counted as code (e.g., ASN.1 schemas).

I'm thinking that this may be our best answer, unless we are sure that we 
can come up with definitive ways of telling the difference between code and 
text.

It would have the advantage that the IETF could say "you can use this 
portion, but not that one", without being vulnerable to people who figure 
out new ways of using portions of RFCs as code.

>    will be a major hassle for RFC authors.  I'm not convinced all RFC

Mumble. Are you talking about THE "RFC editors"? or about draft authors? I'm 
confused.

>    I think the implications outlined here are poorly understood.

Although there is darned little about what it means to be a working group 
draft in our process BCPs, we do have this notion; if a draft was important 
enough for a working group to spend time on it, and then forward it for 
review by the entire IETF, was it not important enough for the working group 
to think about how it could be used?

I do agree that it's very likely that the group of people who think about 
(to use the current terminology) "is this code, or is this text?" is a lot 
smaller than the total community, but that just means that many IETF 
contributors won't be annoyed by trying to figure all this out...

Thanks,

Spencer

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 21 Jan 2006 15:16:20 +0100

Steven M. Bellovin wrote:

> or go to https://rt.psg.com

That doesn't work anymore with my browser since summer 2005.
I get the question "accept this certificate", say yes, and
then it hangs eventually resulting in a "broken pipe" error.

Deleting the RGnet root CA and other procedures don't help.

Not the same situation as with the draft tracker, where I
only get a warning that its certificate is expired.  Please
post summaries of open tickets here from time to time.  Bye

---

From: "todd glassey" <[email-masked]>
Date: Sat, 21 Jan 2006 08:23:07 -0800

Frank - may I suggest that you reload the browser then. This is how all of
the OpenSSL based self-signed certs work, and it works for the rest of us.

Todd Glassey

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 21 Jan 2006 19:04:29 +0100

todd glassey wrote:

> may I suggest that you reload the browser then.

No, it's nothing simple and nothing on my side, still the same
"fortified" browser as it was before summer 2005, when I could
access the ticket system.

The symptom for rt.psg.com is unique, not like say amazon.com,
where the pages still work as always, but their server for the
secure images doesn't work anymore with my browser.  After ten
trouble tickets I've given up on that issue.

Apparently SSL3 support is dying out.  Nobody has a clue what
the problem is.  With some test servers all is fine, but not
with e.g. DFN CERT.  I'm not up to debug OpenSSL or whatever
it takes, this TLS stuff is rather complex.

                            Thanks and bye

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 21 Jan 2006 23:51:26 +0100

"Spencer Dawkins" <[email-masked]> writes:

> (changing the subject line, since we are discussing an issue, not the
> issue tracker)
>
> Hi, Simon,
>
>
> I agree, or at least I agree that we need to define how anyone would
> know what is permitted with any particular portion of an RFC, if
> different uses are permitted with different portions of an RFC.

Hi Spencer!  Exactly.  Having different licenses for different
portions of the same document is complicated, so if this approach is
adopted, I believe there must be no ambiguity.

I claim one license is considerably simpler to implement than two, or
even more than two (if "mapping tables" is considered a third item,
which I recall someone suggested).

> Even if we are able to do this now, new ways of using portions of an
> RFC may arise at some point in the future. I'm not sure that twenty
> years ago we would have recognized as code all of what we now see as
> code, and people may come up with ways of using a portion of an RFC as
> code that we don't know about now.
>
> To give a poorly-thought-out example, we seem to like letting people
> use MIBs from our documents, because they can be fed into compilers;
> if we started publishing RFCs in XML2RFC form at some point, I'm not
> sure how we would explain "well, if you feed THIS part of the ASCII
> data into THIS program, that's allowed, but if you feed ALL of it into
> SOME OTHER program, that's not allowed" to anyone outside the IETF,
> much less to a jury.
>
> But please don't critique this poorly-thought-out example unless you
> are arguing that we will never figure out new ways to use portions of
> RFCs, beyond the pragmatic lists of "types of code" that we've been
> discussing so far.

I believe what the community considers to be "code" will change over
time.

Further, I believe sometimes people can be mislead by the form of
code-like parts.  Let's take an example to see what I mean.

I wonder whether people would classify the two paragraphs RFC 2222
below as "code".  When I implemented that part, I translated the text
directly into C code.  Doing so may form a derived work.  I claim
labeling this sections as "code" would be appropriate, considering how
it is intended to be used.

However I'm not convinced that any technical WG, especially those that
simply want to get things done quickly, will take up their precious
time to discuss which section should be classified as code and which
as text.  Nor do I believe there is any significant advantage in
making them pay for that extra work.

Quoting RFC 2222 section 7.2.1:

   The client calls GSS_Init_sec_context, passing in 0 for
   input_context_handle (initially) and a targ_name equal to output_name
   from GSS_Import_Name called with input_name_type of
   GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
   "service@hostname" where "service" is the service name specified in
   the protocol's profile, and "hostname" is the fully qualified host
   name of the server.  The client then responds with the resulting
   output_token.  If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED,
   then the client should expect the server to issue a token in a
   subsequent challenge.  The client must pass the token to another call
   to GSS_Init_sec_context, repeating the actions in this paragraph.

   When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes
   the following actions: If the last call to GSS_Init_sec_context
   returned an output_token, then the client responds with the
   output_token, otherwise the client responds with no data.  The client
   should then expect the server to issue a token in a subsequent
   challenge.  The client passes this token to GSS_Unwrap and interprets
   the first octet of resulting cleartext as a bit-mask specifying the
   security layers supported by the server and the second through fourth
   octets as the maximum size output_message to send to the server.  The
   client then constructs data, with the first octet containing the
   bit-mask specifying the selected security layer, the second through
   fourth octets containing in network byte order the maximum size
   output_message the client is able to receive, and the remaining
   octets containing the authorization identity.  The client passes the
   data to GSS_Wrap with conf_flag set to FALSE, and responds with the
   generated output_message.  The client can then consider the server
   authenticated.

> Mumble. Are you talking about THE "RFC editors"? or about draft
> authors? I'm confused.

Sorry, I meant people who write I-D's and RFCs.

On a tangent, I wonder whether the RFC editor (and now I'm really
talking about THE RFC editor) contributions submitted to the IETF
under the same permissions as other contributions?  The person doing
editorial fixes for the RFC editor have copyright claims on his work,
if it is substantial.

> Although there is darned little about what it means to be a working
> group draft in our process BCPs, we do have this notion; if a draft
> was important enough for a working group to spend time on it, and then
> forward it for review by the entire IETF, was it not important enough
> for the working group to think about how it could be used?

Yes, however...

> I do agree that it's very likely that the group of people who think
> about (to use the current terminology) "is this code, or is this
> text?" is a lot smaller than the total community, but that just means
> that many IETF contributors won't be annoyed by trying to figure all
> this out...

...I believe technical WGs are not the best place to think about and
decide about the legal aspects of their document.  I have a hope that
people can agree to publish all IETF documents under a free license
(possibly permitting some rare exceptions when other SDOs want to
publish their documents through the IETF).  Then the technical WGs
will have one less legal issue to discuss and debate before getting
their work done.

My experience has been that often when legal issues are debated in
technical working groups, productivity decreases and frustration
grows.

Regards,
Simon

---

From: John C Klensin <[email-masked]>
Date: Sat, 21 Jan 2006 17:57:01 -0500

--On Saturday, 21 January, 2006 23:51 +0100 Simon Josefsson
<[email-masked]> wrote:

>> I agree, or at least I agree that we need to define how
>> anyone would know what is permitted with any particular
>> portion of an RFC, if different uses are permitted with
>> different portions of an RFC.
> 
> portions of the same document is complicated, so if this
> approach is adopted, I believe there must be no ambiguity.
>...

FWIW, these are the reasons I suggested, some time ago, that we
start maintaining a separate archive of whatever authors, WGs,
the IETF, etc., consider to be "code", and then create a license
for those archives that is potentially different from the
license for the documents.  That obviously has its own set of
disadvantages, but it at least avoids the problems associated
with people trying to deduce which license(s) applies to which
parts of the same document/file.

    john

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 21 Jan 2006 15:15:34 -0800

> access the ticket system.

For what it is worth, here is what you get when you try to access <>
using IE7 on a beta version of Windows Vista:

	<Big Red Icon, signaling danger>
	<bold, large> 
	The site's security certificate has a problem. 
 	This organization's certificate is not from a trusted
certification 	authority. 
	We recommend that you close this webpage and do not continue to 
	this website.
	</bold>
	<smaller>
  	Click here to close this webpage. 
 	Continue to this website (not recommended). 
	</smaller>

You can indeed override this, and "continue to this website". But I am
not sure we really want to encourage people to do that.

The problem is user perception. Steve should be familiar with that. A
self signed certificate is only any good if the reader somehow has
verified it via some secure exchange. Otherwise, it is very easy to
mount a spoofing attack, which in that particular case would easily
harvest user names and passwords. If we tell IETF members to "just
continue", we are in fact teaching users to ignore security warnings. 

I am sure the IETF can do better than that. One solution would be to
encourage web site to use certificates signed by one of the recognized
certificate authorities. Failing that, the second best may be to have
IETF-endorsed sites use certificates signed by an IETF-sponsored
authority. We could then distribute the corresponding authority
certificate to IETF members.

Think about it. The IETF should really be an example for Internet users.

-- Christian Huitema

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 22 Jan 2006 11:22:16 +0100

Christian Huitema wrote:
 
> You can indeed override this, and "continue to this website".
> But I am not sure we really want to encourage people to do
> that.

Maybe IE7 beta can import Randy's root CA certificate somehow:
http://rt.psg.com/  Fingerprints published, of course you have
to trust that what you see are the real rt.psg.com pages.
 
What you got sounds like "working as designed", unfortunately
not my problem in this case...

> The problem is user perception.

...ACK, but that's a different problem.  My "user perception"
is worse for the draft tracker site, because my UA will tell
me again and again that the offered Thawte certificate expired
Mon, Jul 27, 1998.  Of course that's another problem, it used
to work recently (2005).

> I am sure the IETF can do better than that.

Maybe, but it's not trivial.

> Think about it. The IETF should really be an example for

There might be ways to bypass all this complex TLS stuff for
read access on a site with known credentials ietf:ietf.  BASIC
authentication might be good enough.  If the only purpose is
to keep misbehaved spiders out (?)
                                  Bye, Frank

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 22 Jan 2006 16:57:10 +0100

> parts of the same document/file.

I agree that is one solution.  I don't think it is a good one.  Code
may be tightly integrated with the text and separating them may
decrease the readability of standards.  It also create new problems,
like how to handle revisions and errata.  We have a process for that
with RFCs, even if it sometimes work less than perfect.  Creating
another standardization path within the IETF seem sub-optimal to me.

Having one permissive license for the entire RFC is another solution.
I believe it is the best idea that I've seen.  The only problem with
the idea seem to be fears about what some people will do with the
rights they are given, which I believe are either unfunded fears or
easily preventable.

Regards,
Simon

---

From: "todd glassey" <[email-masked]>
Date: Sun, 22 Jan 2006 08:53:35 -0800

Simon, if you stand fast that the code must be able to be threaded through
text then it seems that the only way to win here is either by something, a
section, that would be added to the ID or RFC template that specifically
called for the CODE that was being licensed for derivative use, to be used
as such, or my feeling is that as a number of us have said, the only other
possible clean-fix is a blanket derivative use license for all of the
documents.

There is however a  problem with that, and the problem is thta this will cut
down on the number of possible users of the IETF process since some wont
legally be able to address this derivitive use license issue, which then
folds into another larger question that being how one addresses those
sources of reference code for which the IETF would not have title or rights
like say something that referenced a piece of code ITU controlled or that
some other GSO controls the copyright and derivative rights against.

Todd

---

From: "Lawrence Rosen" <[email-masked]>
Date: Sun, 22 Jan 2006 09:30:43 -0800

> There is however a  problem with that, and the problem is 
> thta this will cut down on the number of possible users of 
> the IETF process since some wont legally be able to address 
> this derivitive use license issue, which then folds into 
> another larger question that being how one addresses those 
> sources of reference code for which the IETF would not have 
> title or rights like say something that referenced a piece of 
> code ITU controlled or that some other GSO controls the 
> copyright and derivative rights against.

If IETF and its users can't, we won't. Like the Internet we'll just have to
route around certain kinds of failure.

It generally isn't that difficult to write anew copyrighted code (or text)
that isn't available for license. In the absence of patents, there's no law
to prevent it.

/Larry

** Lawrence Rosen
** Rosenlaw & Einschlag, technology law offices
** Stanford University School of Law, Lecturer in Law
** 3001 King Ranch Road, Ukiah, CA 95482
** 707-485-1242  *  fax: 707-485-1243
** Author of "Open Source Licensing: Software Freedom
**    and Intellectual Property Law" (Prentice Hall 2004)
** [www.rosenlaw.com]  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of todd glassey
> Sent: Sunday, January 22, 2006 8:54 AM
> To: Simon Josefsson; John C Klensin
> Cc: [email-masked]; Spencer Dawkins
> Simon, if you stand fast that the code must be able to be 
> threaded through text then it seems that the only way to win 
> here is either by something, a section, that would be added 
> to the ID or RFC template that specifically called for the 
> CODE that was being licensed for derivative use, to be used 
> as such, or my feeling is that as a number of us have said, 
> the only other possible clean-fix is a blanket derivative use 
> license for all of the documents.
> 
> There is however a  problem with that, and the problem is 
> thta this will cut down on the number of possible users of 
> the IETF process since some wont legally be able to address 
> this derivitive use license issue, which then folds into 
> another larger question that being how one addresses those 
> sources of reference code for which the IETF would not have 
> title or rights like say something that referenced a piece of 
> code ITU controlled or that some other GSO controls the 
> copyright and derivative rights against.
> 
> Todd
>

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 22 Jan 2006 12:59:53 -0500

>to keep misbehaved spiders out (?)

There is no purpose; it's an accident of the way rt works.  As I 
understand the setup -- I've never installed it myself -- there's no 
easy to way to configure things so that administrator acces (Harald and 
myself, in this case) can use https, while everyone else uses http
and/or has no password.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 22 Jan 2006 13:06:19 -0500

In message <[email-masked]
>Think about it. The IETF should really be an example for Internet users.
In the abstract, you're absolutely correct.  If and when the Tools team 
ever builds an official tracker, or if the new administrative entity 
ever provides an official one, I'm sure it will have a real 
certificate.  For now, we have to make do with what volunteers have 
provided us.

In this particular case, I did perform and state the security analysis: 
there is nothing at risk for anyone but Harald and myself.  I should 
have published the URL of a PGP-signed copy of the CA certificate used; 
you can find it at http://www.psg.com/ca-crt.txt .  I am assuming that 
IETF paricipants are more sophisticated about such matters than most.

I could say more, but it would be getting far off-topic, so I'll 
refrain.

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 22 Jan 2006 19:33:16 +0100

"todd glassey" <[email-masked]> writes:

> text

That was my observation of existing documents, it was not my opinion.
My guess is that future documents will look similar.

> then it seems that the only way to win here is either by something,
> a section, that would be added to the ID or RFC template that
> specifically called for the CODE that was being licensed for
> derivative use, to be used as such,

That seem to lead to the code vs text double license situation, which
I believe is problematic.

I don't say a double license situation is unworkable -- I have been
exploring the double license approach privately, asking some relevant
organizations to give comments -- but I'd like for this WG to make
that decision when we know what the advantages and disadvantages are.

By rushing into the code vs text solution, we may end up with a
situation where other WG's will dislike having to spend time marking
up their documents, or whatever suggestions this WG will end up
giving.

If there is a simpler and better solution, we should not close our
eyes looking for it now.

> or my feeling is that as a number of us have said, the only other
> possible clean-fix is a blanket derivative use license for all of
> the documents.

I don't want to see a "blanket" derivative use, instead one that is
permissive enough to let the work be used in implementations of IETF
output.  My draft contain the license text I believe would be
appropriate.  I believe a license similar to that would further the
goals of people who bring stuff to the IETF.

> legally be able to address this derivitive use license issue,

There has been vague references to this earlier.  Can you expand on
this?  What do you mean by not "be able to address the derivative use
license"?  Today (at least per RFC 2026) the IETF is given rights to
modify and update the document you submit to the IETF, so by
submitting something the original author has lost full control of its
material.  That is inevitable, and I claim that it improve the
Internet in the long run.

> which then folds into another larger question that being how one
> addresses those sources of reference code for which the IETF would
> not have title or rights like say something that referenced a piece
> of code ITU controlled or that some other GSO controls the copyright
> and derivative rights against.

That is a different discussion.  Having exceptions, and other
licenses, for when IETF re-publish some other organizations material
would be fine, although sub-optimal.

However, typical IETF documents does not look like that today.  I
believe most documents these days are developed targeted specifically
for the IETF, and given to the IETF community with the knowledge that
the author loses some control of how it is used.

The documents with ITU controlled material could simply be owned by
ITU and have a restrictive license, unless the ITU is willing to
re-license its work.  There IS advantages in having material freely
available.  I believe we should try to influence the ITU to release
its workings under a permissive license too.

Thanks,
Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Jan 2006 13:57:59 +0100

> another standardization path within the IETF seem sub-optimal to me.

I don't think John's proposal would do that, in fact, but there's
an easier way, which is <code>...</code> tags in the text. That has another
advantage - it answers the question "what is code?" existentially:
code is the stuff between the tags. Take that as a model, and we
can concentrate on the harder question: can we devise two different
license regimes, one for code and one for text?

     Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 23 Jan 2006 07:33:10 -0600

> license regimes, one for code and one for text?

I agree that knowing what is between <code>...</code>, or perhaps between 
<derivedOK>...</derivedOK> tags, would be useful, no matter what use 
(separate repository, pointer to different licencing, whatever). Using 
<derivedOK>...</derivedOK> tags would let us bypass the "what is code?" 
discussion.

I can see someone popping up in ten years and saying, "we have a new and 
exciting way to use ASCII characters extracted from RFCs, this is clearly 
code, even though the participants had no idea it was code, ten years ago". 
Isn't "covered under a different licence" what we're trying to capture?

Thanks,

Spencer

---

From: John C Klensin <[email-masked]>
Date: Mon, 23 Jan 2006 16:00:10 -0500

--On Monday, 23 January, 2006 13:57 +0100 Brian E Carpenter
<[email-masked]> wrote:

>> I agree that is one solution.  I don't think it is a good
>> one.  Code may be tightly integrated with the text and
>> separating them may decrease the readability of standards.
>> It also create new problems, like how to handle revisions and
>> errata.  We have a process for that with RFCs, even if it
>> sometimes work less than perfect.  Creating another
>> standardization path within the IETF seem sub-optimal to me.
> 
> I don't think John's proposal would do that, in fact, but
> there's an easier way, which is <code>...</code> tags in the
> text. That has another advantage - it answers the question
> "what is code?" existentially: code is the stuff between the
> tags. Take that as a model, and we can concentrate on the
> harder question: can we devise two different license regimes,
> one for code and one for text?

Just to clarify what I was proposing...

(1) I was _not_ proposing eliminating the code excerpts from the
documents.  They would presumably continue to be in the
documents, and _those_ copies/ expressions of the code would
continue to be covered by whatever licenses covered the
document.   In addition, we would copy out whatever we consider
"code", keep it in a separate/ additional archive (without page
headers and other formatting irritations) and license the use of
that archive as we find appropriate for "code".     Of course,
that leaves the question of what two different license regimes
would look like, as Brian points out.

(2) I am not persuaded that putting <code> ... </code> tags
around things we consider to be "code" is as simple a cure as
would appear on first glance.  We would have to work out the
structure of the elements subsidiary to the <code> element
rather carefully and I'm not sure it is feasible, at least
without a lot of clutter.  For example, I can easily imagine
part of a code element being a chunk of ABNF that one would like
checked by the processor.  The elements needed to identify the
ABNF and its components would be clutter (at least as bad as
page headers and footers) relative to a requirement
to extract material for use in some code segment or interpreted
table.  In that context, note also that the examples in RFC 4234
might not be material we would want to treat as code but might
still want to check.  On the other hand, if <code>...</code>
were feasible, it would provide a convenient way to identify
material in a source document that was to be automatically
copied into the code archive.

(3) I am (also) still not yet persuaded that distribution of the
XML form of RFCs as the base archival format would be in the
IETF's best interest.  I remain convinced that it should be
permitted as an input form to the RFC Editor and that
substantive and copy editing should be done in that form, used
for interactions with authors, and available after publication
on more or less the same basis that the nroff source has
traditionally been available.  I also believe that XML source
would be appropriate for group editing use within WGs and hence
that posting of XML-form I-D along with ASCII ones would be
appropriate.  But my instincts tell me that the final/ public/
archival form of our RFCs should be in a presentation format
that does not require processing via external tables or
equivalent, tables that may themselves change over time,
impacting formatting and possibly structure, in order to read
effectively.  

fwiw, of course.
    john

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jan 2006 10:51:28 +0100

John,

> would appear on first glance.  

Oh, it's simple, the question is whether it's a cure :-)

> We would have to work out the
> without a lot of clutter. 

I think you're reading more into it than I intended. It's only
a label, meaning "the author or WG decided to describe this part
as code." It doesn't imply that the text carrying that label
conforms to any specific syntax, in my mind.

> IETF's best interest. 

I agree; that case is not proven although it has attractions.
I used <code> which is pseudo-XML, but I could equally well have
used pseudo-nroff or any other form of tag.

     Brian

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Jan 2006 13:09:04 +0100

> would look like, as Brian points out.

I note that this may also allow authors to _later_ re-license parts of
the specification as "code", if people is able to convince the author
that some specific section ought to be more freely available.  I
believe that is a good property.

However, it may not be realistic, since many people may have
contributed to the particular part, and it may be impossible to find
all authors later on, or even know who contributed to it.  It is not
sufficient to talk with the authors named on the document, all authors
with copyright claims would need to agree.

If the entire document was published under a permissive license, this
problem wouldn't exist.  All contributors presumably agreed to
BCP78(bis).

> would appear on first glance.

It has the disadvantage that authors and WGs will need to think
carefully about where to put those tags.  That will take time, and I'm
not sure how popular such work would be.  It is also quite some work
to change it later on, you'd have to re-issue the RFC changing the
markup, after asking all relevant contributors.

> We would have to work out the structure of the elements subsidiary
> to the <code> element rather carefully and I'm not sure it is
> feasible, at least without a lot of clutter.  For example, I can
> easily imagine part of a code element being a chunk of ABNF that one
...

I don't think we need that.  As I understood it, <code>...</code> was
meant for human parsing.

Thanks,
Simon

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 24 Jan 2006 06:48:42 -0600

Hi, John (Klensin),

I'm not sure we're in sync here, so needed to ask - if the technical 
publisher has XML for approved RFCs, were you thinking that anyone could 
retrieve it, even if the "base archival format" was something else (like 
formatted ASCII text)?

If "yes", I'm thinking that the question (people figuring out ways to 
process the XML in ways that authors/editors/working groups never 
anticpated, so that what was once "not code" becomes "code") is still 
relevant, no matter what the base archival format happens to be.

Thanks,

Spencer

---

From: John C Klensin <[email-masked]>
Date: Tue, 24 Jan 2006 08:11:20 -0500

> Oh, it's simple, the question is whether it's a cure :-)

Right.

> conforms to any specific syntax, in my mind.

Yes, but, were it to be XML, or inserted in the XML, then there
are constraints on what one can do with elements or subsidiary
elements, or at least issues in complexity of DTDs/ schema and
processing.

In the final, human-readable, form of the document, one could
presumably adopt a convention such as:

  3.2.1 Foo bar baz (special code license applies to this
section)

or a licensing section that would say

  9.9.9 Licensing
  <standard boilerplate>
  The following additional license applies to sections N, M, P...
and/or 
  ... sections identified with the phrase "(special code
license..."

Still not very nice in terms of inserted page headers/footers
and perhaps a bit tedious for code expressed in tables, etc.,
but more reasonable for humans than pseudo-tags in
output/distribution documents and, fwiw, easily done in XML.

>> (3) I am (also) still not yet persuaded that distribution of
>> the XML form of RFCs as the base archival format would be in
>> the IETF's best interest. 
> 
> I used <code> which is pseudo-XML, but I could equally well
> have used pseudo-nroff or any other form of tag.

But the point I was trying to make was that we don't generally
distribute pseudo (or real)-nroff for RFCs either.  And I see a
huge difference between "this is the primary
archival/distribution form" and "this is an editing source form
that is available on request to those who have a legitimate need
to modify/update/pick apart the document".  

Part of that difference is that I'm skeptical about ever getting
a generic markup system to produce the right formatting in every
case.  The RFC formats have benefited immensely in readability
from the fact that the RFC Editor is flexible about formats,
making slight adjustments when needed for individual documents.
If we focus on generic markup to get the text and rough (more
than good enough for I-Ds) formatting right, but assume the RFC
Editor will take some appropriate output from processing of the
source language as input to final formatting and adjust
accordingly, we will preserve the quality of today's formatting
or maybe even be able to improve on it.  Publishers do those
sorts of formatting modifications either in an intermediate
formatting or page-make-up system or by making per-document
changes in the processor or its tables.  But, as soon as such
modifications are made, the output of the standard XML (or
whatever) processor, processing the standard generic markup, may
be different from the published/ distributed/ archival form and
that creates a small mess when the latter is generally available
and distributed.

Perhaps a trivial example will help illustrate what I'm talking
about here.  The normal convention with RFCs is that indention
does not change with section nesting.  So, if we have (using XML
as a convenience)...

   <section title="foo">
   <t> some text</t><t>more text</t>
   <section title="bar">
   <t>text for bar</t></t>more bar</t></section>
   <t> blather</t></section>

Now, as RFCs are normally formatted (and, consequently, as
XML2RFC works), there is no way to determine visually from the
output whether "blather" is the third paragraph of "bar" or
whether "bar" has ended and "blather" is closing text n "foo".
Normally, it doesn't make any difference.  But, when it has been
important, the RFC Editor has managed to set the "bar" text off
by further intention or extra vertical spacing so as to make the
distinction clear.  Now, one could modify XML2RFC to permit
specifying this formatting, e.g., by permitting a 
   "format='betterMakeThisSubsectionDistinct'"
parameter on "<section>", but, as others have pointed out, the
big advantage of generic markup is not having to worry about
this sort of low-level formatting stuff.  There are also many
cases similar to this, with many implications and side-effects
(including the obvious one if there are more than one subsection
of "foo").

      john

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 25 Jan 2006 17:35:16 -0800

I have created ticket #1175 on the issue of distinguishing code from 
non-code.
This is a separate issue from whether or not we SHOULD distinguish the two.
Text of issue, so far:

Subject:	How can code be distinguished from non-code?	

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. 
Suggestions include:
- Defining it by type (C code, ABNF, MIBs...)
- Defining it by marker (<code>/</code>)
- Defining it by separate submission (file alongside draft)
If there are no such differences, the point is moot.