Re: Last Call: draft-ietf-lemonade-rfc2192bis (IMAP URL Scheme) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dave Cridland <dave@xxxxxxxxxxxx> writes:

>> The conclusion remains that if the ABNF in this particular document
>> is
>> made available under a more liberal license, it will make
>> implementations of this particular document easier and more
>> reliable.
>> That should be in the interest of the IETF.
>
> I readily agree that we should have ABNF treated as code which may be
> incorporated directly or indirectly into implementations under a
> liberal license, and I think you're quite right to raise this issue.
>
> I disagree that this document is the place to start what I suspect
> would be a fairly lengthy process.

Right, and I have brought this up within the IPR WG.  As you suspect,
the effort to revise the license is a multi-year effort.

I don't think it is reasonable to ask implementers to wait for the IPR
WG process to finish before potentially being able to more easily
implement RFC 2192bis.  It should be in the IETF's interest to make it
easy to implement all standards in a reliable way.  In this case, there
is something the IETF community and the document authors can do to help
improve the situation.

> RFC4234bis, on the other hand, could reasonably start to address this
> from the ground up, and I feel that's the place to direct your
> energies.

I see those as separate efforts -- improving RFC 4234bis is a worthy
cause, but improving that document shouldn't prevent us from improving
RFC 2192bis too.

> I'd personally expect that ABNF was treated as "executable code or
> code fragments" under BCP78, Section 3.3(a)E, much like a MIB, and
> hence your concerns would seem misplaced. Of course, clarifying this
> would be welcome, but the text within BCP78 is not referenced
> explicitly nor copied into recent MIB RFCs, and nor is that text
> limited to MIBs - MIBs are merely one example given - so I would be
> surprised if this weren't intended to be the case for ABNF as well.
>
> Relatively recent comments I've seen have suggested to me that at
> least some other RFC authors believe that the ABNF can be extracted
> and used in the process of implementing a parser, for example
> http://mailman1.u.washington.edu/pipermail/imap-protocol/2006-March/000136.html
> (Mark Crispin, referring to ABNF from RFC3501, "[...] you should use
> one of the excellent syntax generators that read ABNF.")
>
> So unless I'm completely misreading what BCP78 says - and in that case
> I'm not the only one - I think we're covered anyway.

I think you are missing what I tried to explain in my initial e-mail:
Read Section 3.3 of BCP78 from the start.  It starts by defining who
gets the rights discussed later on, including 3.3(a)E:

3.3.  Granting of Rights and Permissions
...
   a. To the extent that a Contribution or any portion thereof is
      protected by copyright and other rights of authorship, the
      Contributor, and each named co-Contributor, and the organization
      he or she represents or is sponsored by (if any) grant a
      perpetual, irrevocable, non-exclusive, royalty-free, world-wide
      right and license to the ISOC and the IETF under all intellectual
                               ^^^^^^^^^^^^^^^^^
      property rights in the Contribution:

(This is slightly altered by RFC 4748.)

Several people consider this license insufficient to make it possible to
include extracted material from RFCs into some implementations.
Supporters for the effort to revise the IETF licenses include the people
at the bottom of:

http://josefsson.org/bcp78broken/

/Simon

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]