ietf-smtp
[Top] [All Lists]

Re: RFC5321bis / RFC 2821ter

2008-12-16 07:43:23

John,

I'm not privy to all the details of this issue, but I am not quite understanding something:

Doesn't our document should fall under some common sense and "natural law" grandfather clause since its a) it is an update (as opposed to new), b) was initiated prior to RFC 5278 official publication by nearly 25 years?

Based on what I read in provision 2.d of:

   http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf

   2.d. In most cases, rights to Pre-Existing IETF Documents that
   are not expressly granted under these RFCs can only be obtained
   by requesting such rights directly from the document authors. The
   IETF Trust and the Internet Society do not become involved in
   making such requests to document authors.

So it sounds to me, the trust is not making claims to prior art (Pre-existing IETF Document prior to the effective date November 10, 2008) and it did, it could only do so by contacting the authors of prior art. This is something they do no wish to get involved with in "making such request of document authors."

In addition, in regards to prior art, in section 3.a.ii. it states a License For Use Within the IETF Standards Process where:

        iii: unless explicitly disallowed in the notices contained in
   an IETF Contribution or IETF Document (as specified in Section 6.b
   below), to modify or prepare derivative works of such IETF
   Contributions or IETF Documents, in whole or in part, as part of
   the IETF Standards Process.

So as long as the derivative work remains within IETF and not taken by some company for non-standard proprietary usage, its all good.

I think RFC 5321 fulls under prior art for IETF standards process.

--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


John C Klensin wrote:
Hi.

After a lengthy discussion with my attorney about the RFC5321bis
draft which I had hoped to post within the next week or ten
days, I've reached two conclusions.  These conclusions obvious
do not constitute legal advice, from me or anyone else, to
anyone on the list.  They are simply explanations to this group
about actions I'm taking.  The first of them is inconsistent
with assertions made by the IETF Chair on the IETF list and
elsewhere; I do not have an opinion as to whether his remarks
constitute legal advice or not.

        (1) As long as I am permitted to do so by the posting
        tools and the Secretariat, and at least until the Note
        Well statements are updated, it is reasonably safe to
        post documents that refer only to RFC 3978 and the
        associated boilerplate, if those postings are done for
        IETF Standards purposes, without obtaining an explicit
        release of RFC 5378 rights to the IETF Trust from all
        contributors of text in the document.
        
        (2) Posting a draft that uses text from others and that
        references or incorporates RFC 5378 copyright transfer
        requirement is prohibited unless formal releases of
        rights from all contributors of text are on file with
        the IETF Trust.  Ignoring that prohibition or trying to
        slide around it is not acceptable, at least to me under
        the advice I've been given.

As I presume everyone reading this is aware, RFC 2821 carried
forward a considerable amount of Jon Postel's text from RFC 821.
Most of that text, including some of the formerly-contentious
examples, is still present in 5321 and would have been present
in 5321bis.  While I believe that Jon would have granted the
rights to the IETF Trust that RFC 5378 requires, I have no
plausible way to verify that belief, much less any way to get
the required releases and transfers filed with the IETF Trust.
I have been advised that, if I, as Contributor of the current
versions, have to take personal responsibility for the validity
of such releases as 5378 appears to require, I should not
recognize any such release from Jon's estate unless it is
formally endorsed by a cognizant court _and_ USC/ISI formally
release any rights they might have to his individual work for
the IETF and its predecessors.

I am, and remain, optimistic that the IETF will figure out a way
out of what appears to me to be a self-created impasse.

In order to facilitate making progress in the interim, I've just
queued an I-D, draft-klensin-rfc5321-numbered-00.txt, for
posting (with RFC 3978 boilerplate) that is essentially a
facsimile of RFC5321 with line numbers inserted to permit
precise references to specific text.    There will no -01 of
that document, nor will there be any attempt to have it posted.
I would not have taken that action at this time except that I
expect the window on postings with RFC 3978 boilerplate to close
within the next 48 hours.

Until it is possible to post draft-klensin-rfc5321bis itself,
suggested changes will be posted only as diffs with reference to
those line numbers and without incorporating any text whose
ownership I cannot guarantee to my satisfaction and that of the
IETF Trust.  I hope that these issues can be resolved soon
enough that we do not have to ask the IESG to act on the Diffs,
but note that there does not appear to be anything in RFC 2026
that would prohibit having a base document plus corrections as
an Internet Standard.

Sadly,
    john





<Prev in Thread] Current Thread [Next in Thread>