Re: draft-josefsson-ipr-rules-update-00

[[e-mail]]

 -------------- Original message ----------------------
From: [e-mail] (Scott Bradner)
> 
> Simon lists:
> A list of modifications forbidden by RFC 3978 that I want to be able
> to do:
> 
> * Typographical changes.  Compare the table at:
>   http://josefsson.org/gss/manual/gss.html#Context_002dLevel-Routines
>   with the table in section 2 of RFC 2744.  I have added punctuation
>   because the RFC uses inconsistent punctuation, and I have removed
>   the "section" column because that column refer to RFC internal
>   section numbers.

This is actually a larger issue for all of us dyslexic engineers that want to participate - are you thinking of instituting a language-style requirement like passing a strunk & white filter for instance. Might not be a bad idea - would unify the document style which would make one dovcument easier to compare to another.

> 
> >> if the punctuation difference is significant use the errata process
> >> http://www.rfc-editor.org/errata.html
> >> I'd think that a pointer to the correct RFC section would be useful
> 
> * Modify ASN.1 schemas to make minor adjustments.  Compare the ASN.1
>   schema I use for Kerberos 5 in Shishi:
>   
> http://josefsson.org/cgi-bin/viewcvs.cgi/shishi/lib/kerberos5.asn1?rev=1.8&view=
> auto
>   with the ASN.1 schema in RFC 4120.  I had to change 'INTEGER
>   (0..429467295)' into 'INTEGER' because my ASN.1 library do not
>   handle bignums.  

This is more than a style issue - it is an implementation specific recoding - which may be why ASN.1 is not the best of all possible notation schemas since it is implemented at low levels with different functional datatypes - endian, size-wise, etc.

> This doesn't result in any change of protocol
>   behavior, of course.  

But it easily could and this is the problem - that it doesnt in your case is sheer luck.

> Other Kerberos 5 implementation need the same
>   right.  I looked at both MIT Kerberos 5 and Heimdal, and they both
>   ship modified ASN.1 schemas.  In fact, they have modified the
>   schemas considerably more than I have.

In fact since ASN.1 is a pseudocoding framework, it makes sense to have a coding style standard as well. 

> 
> >> sounds like significant changes - i.e., impact interoperability - 
> >> should be done through the IETF standards process
> 
> * Remove non-applicable portions of introductory sections, when
>   incorporating them into my manual.  Compare section 3 of RFC 2222
>   <with http://josefsson.org/gsasl/manual/gsasl.html#SASL-Overview>.
>   I have removed some forward references, such as a sentence:
> 
>    SASL mechanism names must be registered with the IANA.  Procedures
>    for registering new SASL mechanisms are given in the section
>    "Registration procedures".
> 
>   Having that specific sentence in my manual isn't useful for the
>   reader, but the rest of that text is very useful.

Then you have a derivative work...

> 
> >> enabled by draft-ietf-ipr-rules-update-01.txt
> 
> * Extract portions of RFCs into source code comment, after removing
>   line breaks and other material.  See:
>   
> http://josefsson.org/cgi-bin/viewcvs.cgi/gsasl/lib/digest-md5/validate.c?rev=1.8
> &view=auto
>   Most of the comments are taken from the RFC, to document which
>   MUST/SHOULD requirements are translated into 'if' tests.
> 
> >> extracts (not modified) enabled by draft-ietf-ipr-rules-update-01.txt
> 
> * Use tables with Unicode code points from RFCs, e.g., compare RFC
>   3454 with how my Libidn is incorporated in GNU Libc:
>   
> http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/libidn/rfc3454.c?rev=1.1&conte
> nt-type=text/x-cvsweb-markup&cvsroot=glibc
>   The tables are modified heavily, typographically, from the RFC.

Which brings us back to the question - what does the IETF or ISOC plan to do about people who violate the use rules with the materials the ISOC is contracting with the submitters to protect.

> 
> >> sounds like significant changes - i.e., impact interoperability - 
> >> should be done through the IETF standards process
> 
> * Extract function comments into source code, and be able to improve
>   them over time.  E.g., compare RFC 2744 with:
>   http://josefsson.org/cgi-bin/viewcvs.cgi/gss/lib/context.c?rev=1.31&view=auto
>   That file contain comments derived from the RFC, but sometimes I
>   have improved on the function description with more information that
>   the end-user may find helpful.
> 
> >> extracts (not modified) enabled by draft-ietf-ipr-rules-update-01.txt
> >> append improvement to end of extracted material or just replace 
> >> extract
> 
> >> looks like the significant difference is where you want to make
> >> significant (in terms of interoperability) changes (the rest of your 
> >> examples seem cosmetic) - it is my opinion that inetroperability-impacting
> >> changes should be done through the IETF Standards Process for IETF
> >> documents
> 
> Scott
> 
> _______________________________________________
> Ipr-wg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ipr-wg



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