headers
Simon Josefsson | 2 May 11:38

Re: A simpler idea

Ted Hardie <hardie <at> qualcomm.com> writes:

> At 10:54 AM +0200 4/28/06, Simon Josefsson wrote:
>>
>>Con:
>>
>>* Some people are afraid of fake RFCs.  I don't think this is a good
>>  enough argument, the costs of copyright transfers or regular updates
>>  of the IETF license are, I believe, larger than the risk of fake
>>  RFCs.
>
> This is only part of the risk.  If we release specs into the wild
> with this license, there is not just risk that someone fakes RFC
> XXXX, there is a much larger risk that someone takes the text and
> uses it as the basis for a specification that does not interoperate
> with the IETF spec.  It moves us to a model, in other words, where
> forking is a generally permitted result.  Getting to consensus is
> hard work, and forking is relatively easy (especially if you start
> from a finished work).  I believe that this will result in a
> situation in which forking is a common result.

I'm less sure of that.  Forking is permitted by free software
licenses, yet the large free software projects are rarely successfully
forked, and when they are forked it often leads to something that is
useful.  Unsuccessful forks may occur, but the confusion from those
are, in my experience, limited (since few know about the fork) and
temporary (when interested people learn about the facts).

Also, I argue that having the ability to fork specifications improve
experimentation with protocols.  Eventually, experiments typically end
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Josefsson | 2 May 11:57

Re: A simpler idea

"David B Harrington" <dbharrington <at> comcast.net> writes:

> Hi,
>
> While I believe it is important to try to constrain the use of RFCs
> for activities that are supportive of interoperability and standard,
> we need to make sure we don't make it illegal to create running code
> that is a variation of an existing standard; that's how standards get
> improved.
>
> The IETF depends on running code, but the IETF does not develop
> running code, so we need to be sure other people can develop running
> code that can later be brought to the IETF as a contributions to the
> standards process. And it is an economic reality that most running
> code gets developed as a proprietary product feature that vendors can
> sell to recoup their research and development costs. I don't want to
> see us write text here that discourages vendors from doing this.

I agree fully!

> I think the existing approach seems to work fine, and has worked fine
> for years, and wonder why is this WG trying to change this? Is there a
> known problem we are trying to solve?

There are several known problems, see
<http://josefsson.org/bcp78broken/>.

I believe a good-faith company that tweaks an IETF standard to make
the protocol becomes better should be permitted (and encouraged) to
document it in a format that makes it easy to pursue the protocol
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Josefsson | 2 May 12:02

Re: #1273 How do we usefully define "excerpt"?

"Tom Petch" <nwnetworks <at> dial.pipex.com> writes:

>> > * Fix spelling typos
>>
>> Opinion: OK, as is translation from English
>>
> Disagree, your fixing a typo is my change of meaning; even a change of
> punctuation can change the meaning.

Changing the meaning isn't fixing a typo.  If fixing a typo changes
the meaning of the protocol, it is no longer a "good-faith" typo fix.

There may be edge cases, but I'd say that if a "typo fix" leads to
even minor technical differences, it isn't a "typo fix" anymore, but
must be treated as a "modification".

(Of course, I argue that modifications should be permitted as well,
but that is another discussion.)

Regards,
Simon
Permalink | Reply | 7 comments |
headers
Ted Hardie | 2 May 19:55
Favicon

Re: #1273 How do we usefully define "excerpt"?

At 12:02 PM +0200 5/2/06, Simon Josefsson wrote:
>"There may be edge cases, but I'd say that if a "typo fix" leads to
>even minor technical differences, it isn't a "typo fix" anymore, but
>must be treated as a "modification".

The problems really come in when the individual doesn't fully understand
what is being specified and fixes it to something they do understand.  In
one recent exchange with a technical editor, for example,  "uuencoded" got
fixed to "unencoded".  I presume that the editor did not know what
uuencoded meant, and did know what unencoded meant; the paragraph
made sense with "unencoded" in that slot, but that wasn't what was intended.

I think the discussion so far has convinced me that the appropriate way
to handle this is to make the correction in commentary, e.g. "This is specified
in the RFC as  BAR = numchar, but I believe that BAR = 1*numchar was
meant, and I have implemented accordingly" .  I would obviously suggest
putting in an erratum for the RFC as well.

For typos like "there implementation", insert a "sic" if you can't stand leaving
it, and be done.

Two cents from the peanut gallery,
				Ted

>(Of course, I argue that modifications should be permitted as well,
>but that is another discussion.)
>
>Regards,
>Simon
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
John C Klensin | 2 May 20:00

Re: #1273 How do we usefully define "excerpt"?


--On Tuesday, 02 May, 2006 10:55 -0700 Ted Hardie
<hardie <at> qualcomm.com> wrote:

> At 12:02 PM +0200 5/2/06, Simon Josefsson wrote:
>> "There may be edge cases, but I'd say that if a "typo fix"
>> leads to even minor technical differences, it isn't a "typo
>> fix" anymore, but must be treated as a "modification".
> 
> The problems really come in when the individual doesn't fully
> understand what is being specified and fixes it to something
> they do understand.  In one recent exchange with a technical
> editor, for example,  "uuencoded" got fixed to "unencoded".  I
> presume that the editor did not know what uuencoded meant, and
> did know what unencoded meant; the paragraph made sense with
> "unencoded" in that slot, but that wasn't what was intended.
> 
> I think the discussion so far has convinced me that the
> appropriate way to handle this is to make the correction in
> commentary, e.g. "This is specified in the RFC as  BAR =
> numchar, but I believe that BAR = 1*numchar was meant, and I
> have implemented accordingly" .  I would obviously suggest
> putting in an erratum for the RFC as well.

Of course, such commentary is of the nature of a critical review
and does not raise any of the same copyright issues as
incorporating the original text in modified form.

> For typos like "there implementation", insert a "sic" if you
> can't stand leaving it, and be done.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Simon Josefsson | 2 May 21:17

Re: #1273 How do we usefully define "excerpt"?

John C Klensin <john-ietf <at> jck.com> writes:

>> I think the discussion so far has convinced me that the
>> appropriate way to handle this is to make the correction in
>> commentary, e.g. "This is specified in the RFC as  BAR =
>> numchar, but I believe that BAR = 1*numchar was meant, and I
>> have implemented accordingly" .  I would obviously suggest
>> putting in an erratum for the RFC as well.
>
> Of course, such commentary is of the nature of a critical review
> and does not raise any of the same copyright issues as
> incorporating the original text in modified form.

Are you referring to US copyright "fair use"?  That doesn't hold
universally...  granting the same, explicit, rights to everyone appear
preferable.

For brief excerpts, such as a 2-3 sentence function API documentation,
I would disagree that the above is the appropriate solution.

/Simon
Permalink | Reply | 2 comments |
headers
Tom Petch | 2 May 20:34

Re: #1273 How do we usefully define "excerpt"?

----- Original Message -----
From: "Simon Josefsson" <jas <at> extundo.com>
To: "Tom Petch" <nwnetworks <at> dial.pipex.com>
Cc: "Brian E Carpenter" <brc <at> zurich.ibm.com>; <ipr-wg <at> ietf.org>
Sent: Tuesday, May 02, 2006 12:02 PM
Subject: Re: #1273 How do we usefully define "excerpt"?

> "Tom Petch" <nwnetworks <at> dial.pipex.com> writes:
>
> >> > * Fix spelling typos
> >>
> >> Opinion: OK, as is translation from English
> >>
> > Disagree, your fixing a typo is my change of meaning; even a change of
> > punctuation can change the meaning.
>
> Changing the meaning isn't fixing a typo.  If fixing a typo changes
> the meaning of the protocol, it is no longer a "good-faith" typo fix.
>

I repeat, your typo can be my change of meaning,

I saw posts recently along the lines of

A ...SSL....
B ... you mean SSH
A ... no I don't

A had made reference to public keys; B 'knew' that public keys were associated
with SSH while SSL went with certificates so obviously this was a typo; no it
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon Josefsson | 2 May 22:22

Re: #1273 How do we usefully define "excerpt"?

"Tom Petch" <nwnetworks <at> dial.pipex.com> writes:

> ----- Original Message -----
> From: "Simon Josefsson" <jas <at> extundo.com>
> To: "Tom Petch" <nwnetworks <at> dial.pipex.com>
> Cc: "Brian E Carpenter" <brc <at> zurich.ibm.com>; <ipr-wg <at> ietf.org>
> Sent: Tuesday, May 02, 2006 12:02 PM
> Subject: Re: #1273 How do we usefully define "excerpt"?
>
>
>> "Tom Petch" <nwnetworks <at> dial.pipex.com> writes:
>>
>> >> > * Fix spelling typos
>> >>
>> >> Opinion: OK, as is translation from English
>> >>
>> > Disagree, your fixing a typo is my change of meaning; even a change of
>> > punctuation can change the meaning.
>>
>> Changing the meaning isn't fixing a typo.  If fixing a typo changes
>> the meaning of the protocol, it is no longer a "good-faith" typo fix.
>>
>
> I repeat, your typo can be my change of meaning,
>
> I saw posts recently along the lines of
>
> A ...SSL....
> B ... you mean SSH
> A ... no I don't
(Continue reading)

Permalink | Reply | 0 comments |
headers
John C Klensin | 2 May 23:54

Re: #1273 How do we usefully define "excerpt"?


--On Tuesday, 02 May, 2006 21:17 +0200 Simon Josefsson
<jas <at> extundo.com> wrote:

> John C Klensin <john-ietf <at> jck.com> writes:
> 
>>> I think the discussion so far has convinced me that the
>>> appropriate way to handle this is to make the correction in
>>> commentary, e.g. "This is specified in the RFC as  BAR =
>>> numchar, but I believe that BAR = 1*numchar was meant, and I
>>> have implemented accordingly" .  I would obviously suggest
>>> putting in an erratum for the RFC as well.
>> 
>> Of course, such commentary is of the nature of a critical
>> review and does not raise any of the same copyright issues as
>> incorporating the original text in modified form.
> 
> Are you referring to US copyright "fair use"?  That doesn't
> hold universally...  granting the same, explicit, rights to
> everyone appear preferable.

No, I wasn't.  I was referring to the ability of anyone, at any
time, to say "This is an implementation of RFC nnnn, except that
section 666 of that RFC says 'BAR=numchar'.  That appears to be
incorrect and this implementation handles BAR as 1*numchar
instead."

As I understand it, that would not violate copyright laws
anywhere.   To do so would require giving the author of the RFC
ownership of particular words, such as "BAR" and "numchar" and
(Continue reading)

Permalink | Reply | 1 comment |
headers
todd glassey | 3 May 00:58
Picon

Re: #1273 How do we usefully define "excerpt"?

OK how about a simple solution here - lets ask the question "Why would you
allow people to make derivatives of the IP without noticing them as the
IETF's?" - my answer is that you wouldnt. So how about we create registered
and unregistered derivatives which is how you get to use the IETF's TM in
print outside of the standards process.

This way you just say "this protocol is an unregistered derivative of
RFCxxxx's version WabaWaba" if you want to publish the protocol and note its
origin without giving anything back to the IETF.

That way - you dont allow the use of the IETF's TM on it unless it becomes a
registered derivative. And this way all the IETF has to do is bill people
for the registration fee, right? That was what the Trust wanted to do eh?

T.

----- Original Message ----- 
From: "John C Klensin" <john-ietf <at> jck.com>
To: "Simon Josefsson" <jas <at> extundo.com>
Cc: "Ted Hardie" <hardie <at> qualcomm.com>; "Brian E Carpenter"
<brc <at> zurich.ibm.com>; "Tom Petch" <nwnetworks <at> dial.pipex.com>;
<ipr-wg <at> ietf.org>
Sent: Tuesday, May 02, 2006 2:54 PM
Subject: Re: #1273 How do we usefully define "excerpt"?

>
>
> --On Tuesday, 02 May, 2006 21:17 +0200 Simon Josefsson
> <jas <at> extundo.com> wrote:
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane