Ted Hardie <hardie(_at_)qualcomm(_dot_)com> writes:
At 6:41 PM +0200 6/14/07, Simon Josefsson wrote:
The ABNF syntax is the most important, since being compatible with the
technology requires that you follow the formal definition of the URL.
Implementations cannot integrate the ABNF as-is today. The alternative
for them, to re-specify the module from the text (if that is at all
possible), is bad for interoperability. If you want to enable smooth
implementation of your standard by everyone (which I hope!), here is how
to solve it:
Simon,
I follow your argument for the sample code in Appendix A,
but I don't follow it for the ABNF. What do you mean by "integrate
the ABNF as-is today"?
I mean: To extract from the document the ABNF syntax specification and
include it in an implementation. For example, a generic parser that
uses the ABNF specifications as input. That is not possible today.
As I understand it, a developer reading the
specification and using the ABNF to develop an implementation is
within the "outbound rights" understood by the IETF community
to pertain to standards track RFCs. Indeed, it's kind of the whole
point. Is there something special about this document that causes
you to believe that it needs special licensing for the specification?
I believe our disagreement is that the "outbound rights" in the IETF
license permits extracting and use of the ABNF syntax specification in
implementations. In my initial post I explained this as follows:
The rights granted by the IETF license in RFC 3978/4748 in section
3.3, including the right to extract code portions from documents into
products etc, are only granted to "IETF Trust and the IETF", and
there is no other license to indicate that any similar rights are
granted to third parties.
If you do believe the ABNF needs special licensing in
this case, I am sorry to say that your remedy is not sufficient. This
document imports ABNF from other documents (from RFC 3986,
to take one important example). Those documents do not have
anything like what you suggest.
True, but I don't believe that is relevant to the document under
discussion.
It is possible to avoid extracting the ABNF from the referenced
documents by writing up your own ABNF specification based on
implementations made available under a liberal license. Take for
example:
http://www.ninebynine.org/Software/HaskellUtils/Network/URI.hs
It also _possible_ to implement the RFC 3986 ABNF without extracting the
ABNF specification from that document (but it takes much more time and
is error prone), and then use that implementation in the parser that
includes the ABNF specification inside draft-ietf-lemonade-rfc2192bis.
The new parser will support the draft-ietf-lemonade-rfc2192bis ABNF and
won't violate any copyright, assuming that my suggested remedy is used.
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.
Generally, justifying a new mistake by pointing at older mistakes seems
like a poor approach.
/Simon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf