Subject: Re: Code vs text

From: [email-masked]
Date: Tue, 24 Jan 2006 16:47:39 +0000

How would you deal then with a wrtitten description of the code and its flow? - from a patent point, the narrative of the system is as important as the mechnical descriptions put forth in the claims. My point is that there may be many ID's for which the code portions cannot be extracted or isolated from the text portions of the document as well.

Todd

 -------------- Original message ----------------------
From: John C Klensin <[email-masked]>
> 
> 
> --On Tuesday, 24 January, 2006 10:51 +0100 Brian E Carpenter
> <[email-masked]> wrote:
> 
> > John,
> > 
> >> (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.  
> > 
> > Oh, it's simple, the question is whether it's a cure :-)
> 
> Right.
> 
> >> 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. 
> > 
> > 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.
> 
> 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 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.
> 
> 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
> 
> 
> _______________________________________________
> Ipr-wg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipr-wg

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

---

From: John C Klensin <[email-masked]>
Date: Tue, 24 Jan 2006 15:06:21 -0500

--On Tuesday, 24 January, 2006 16:47 +0000 [email-masked]
wrote:

> How would you deal then with a wrtitten description of the
> code and its flow? - from a patent point, the narrative of the
> system is as important as the mechnical descriptions put forth
> in the claims. My point is that there may be many ID's for
> which the code portions cannot be extracted or isolated from
> the text portions of the document as well.

There is no "patent point".  This discussion has been about
issues in copyright to, and copyright licensing of the text,
possibly including code snippets, pseudocode, interpretable
tables, etc.  Whatever the patent policy is, it doesn't impact
this stuff and this doesn't impact it.  And, fwiw, there have
been zero claims from anyone with obvious competence to have an
opinion (e.g., a law degree and license) that anything more than
our traditional rights to reproduce and distribute in toto are
needed to establish or reference prior art claims.

    john

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 24 Jan 2006 20:27:29 -0800

> And, fwiw, 
> there have been zero claims from anyone with obvious 
> competence to have an opinion (e.g., a law degree and 
> license) that anything more than our traditional rights to 
> reproduce and distribute in toto are needed to establish or 
> reference prior art claims.

I can't understand how your response deals with Todd's point. ["My point is
that there may be many ID's for which the code portions cannot be extracted
or isolated from the text portions of the document as well."]

I'm also not sure what competent blessing you're expecting, John. But if you
want a degreed and licensed lawyer to stand up and say that the current IETF
IPR policies do not have anything to do with establishing prior art claims,
I'll be glad to do so. But please do not read that statement as support for
the current IPR policies, which are deficient in the ways identified here
already. I'm glad there is a project underway to clean them up, including
extending beyond IETF's "traditional rights."

/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 John C Klensin
> Sent: Tuesday, January 24, 2006 12:06 PM
> To: [email-masked]; Brian E Carpenter
> Cc: Simon Josefsson; [email-masked]; Spencer Dawkins
> Subject: Re: Code vs text
> 
> 
> 
> > How would you deal then with a wrtitten description of the code and 
> > its flow? - from a patent point, the narrative of the system is as 
> > important as the mechnical descriptions put forth in the claims. My 
> > point is that there may be many ID's for which the code portions 
> > cannot be extracted or isolated from the text portions of 
> the document 
> > as well.
> 
> tables, etc.  Whatever the patent policy is, it doesn't 
> impact this stuff and this doesn't impact it.  And, fwiw, 
> there have been zero claims from anyone with obvious 
> competence to have an opinion (e.g., a law degree and 
> license) that anything more than our traditional rights to 
> reproduce and distribute in toto are needed to establish or 
> reference prior art claims.
> 
>     john
> 
>