Ted Hardie <hardie@xxxxxxxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf