Re: Last Call: draft-legg-xed-asd (Abstract Syntax Notation X (ASN.X)) to Proposed Standard

Simon Josefsson <simon@josefsson.org> Sat, 13 January 2007 20:39 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5peX-0001oo-8b; Sat, 13 Jan 2007 15:39:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5peV-0001kw-DI for ietf@ietf.org; Sat, 13 Jan 2007 15:38:59 -0500
Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5peU-0003I1-G4 for ietf@ietf.org; Sat, 13 Jan 2007 15:38:59 -0500
Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0DKcGQC024978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Jan 2007 21:38:16 +0100
From: Simon Josefsson <simon@josefsson.org>
To: "Joel M. Halpern" <joel@stevecrocker.com>
References: <E1H5Ufv-0003zq-BX@stiedprstage1.ietf.org> <87mz4n4475.fsf@latte.josefsson.org> <7.0.1.0.0.20070113123251.03520c38@stevecrocker.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:070113:ietf@ietf.org::8herCXvZd4XWQTRw:0RC2
X-Hashcash: 1:22:070113:steven.legg@eb2bcom.com::CwKeFOu5x0uEautA:0SL6
X-Hashcash: 1:22:070113:joel@stevecrocker.com::FUeXmZgDbWTFHnsu:GRBo
Date: Sat, 13 Jan 2007 21:38:16 +0100
In-Reply-To: <7.0.1.0.0.20070113123251.03520c38@stevecrocker.com> (Joel M. Halpern's message of "Sat\, 13 Jan 2007 12\:50\:05 -0500")
Message-ID: <871wly4q87.fsf@latte.josefsson.org>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Status: No, score=-1.5 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
Cc: steven.legg@eb2bcom.com, ietf@ietf.org
Subject: Re: Last Call: draft-legg-xed-asd (Abstract Syntax Notation X (ASN.X)) to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

"Joel M. Halpern" <joel@stevecrocker.com> writes:

> Simon, you are mixing several issues in your note, including strictly
> legal issues and personal preferences.

I bring up only one issue here: Can implementers extract and use the
ASN.1 module for their implementations legally?

> Firstly, it is clear that you (and every other implementor using this
> document) needs the ability to extract and use the ASN.1 include in
> the document.  That is already provided for in BCP 78.  The text he
> included is exactly the text that BCP 78 tells him to include to do
> that.  So there is no problem there.

I explained in my note that BCP 78 does _not_ provide for that.  If
you disagree with that, I think you need to show where BCP 78 gives
third parties the right to extract and use the ASN.1 module.

> Secondly, there is the agreement that implementors, in practice need
> the right to modify the code.
> BCP 78 in section 3.3 E grants the IETF Trust the rights to make such
> code changes, even for use outside the IETF Standards Process.   This
> appears to mean that the IETF Trust can grant the rights that are
> needed.  Steven does not need to make any changes to achieve that.

Sure.  My point is that the implementers are not granted these rights.
What rights the IETF Trust are granted seems irrelevant.

> Then, you go further and ask him to grant modification rights to all
> of the text, not just the code / ASN.1 components.  While you have a
> clearly stated preference for that grant, it is unfair and
> inappropriate of you to assert that the need for that is inherent in
> the problem you raise of implementor modification.

If you read my note again, and especially the last paragraph, you will
see that I quoted the text from RFC 3492 and then said that he might
want to restrict the additional rights that are granted to only the
ASN.1 module.  I think it is unfair to accuse me of asserting that
adding exactly that text is required.  There are many ways to solve
this problem, and I clearly said so.

> So, in summary, while I agree that you need the right to modify the
> ASN.1, I don't think there is anything that can or should be done in
> the document to address that.  The document already has the
> boilerplate components intended to permit that.

No.  The boilerplate present does not give me as third party the right
to extract and use the ASN.1 module.

> If some extra text is needed to ensure modifiablity of the code, it
> should be the code, and not "this entire document or any portion of
> it."

That is up to the each author to decide, of course.

Thanks,
Simon

> Yours,
> Joel M. Halpern
>
> At 05:21 AM 1/13/2007, Simon Josefsson wrote:
>>Hi!  These documents contains normative ASN.1 modules which, if I
>>understand the documents correctly, is typically included in
>>implementations of this standard.  Is that correct?
>>
>>The modules contain this notice:
>>
>>    -- Copyright (C) The IETF Trust (2006). This version of
>>    -- this ASN.1 module is part of RFC XXXX; see the RFC itself
>>    -- for full legal notices.
>>
>>The legal notices used by the IETF doesn't grant third parties
>>(including implementers of your standard) the right to include
>>portions of documents in their implementations.  The rights granted by
>>RFC 3978/4748 in section 3.3, including the right to extract code
>>portions from documents, 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.
>>
>>This raises problems for some implementers, because they can't
>>implement your standard if they use the ASN.1 module.  The alternative
>>for them, to re-specify the ASN.1 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:
>>
>>There are several solutions to this problem.  A simple solution that
>>has been used successfully in several documents (RFC 3492, RFC 4398
>>and a few others) is to add, after the above notice, the following
>>notice:
>>
>>    -- Regarding this entire document or any portion of it (including
>>    -- the pseudocode and C code), the author makes no guarantees and
>>    -- is not responsible for any damage resulting from its use.  The
>>    -- author grants irrevocable permission to anyone to use, modify,
>>    -- and distribute it in any way that does not diminish the rights
>>    -- of anyone else to use, modify, and distribute it, provided that
>>    -- redistributed derivative works do not contain misleading author
>>    -- or version information.  Derivative works need not be licensed
>>    -- under similar terms.
>>
>>Note that should be added to all places where the notice about IETF
>>Trust and legal notices are added.
>>
>>This notice would give third parties the necessary rights they need to
>>be able to use the normative ASN.1 module from your documents.
>>
>>Btw, you'd might want to modify the text slightly, so that "pseudocode
>>and C code" becomes "ASN.1 module".  If you don't want to grant the
>>rights to the entire document, grant them only for the ASN.1 module.
>>
>>Best regards, and thanks in advance,
>>Simon
>>
>>The IESG <iesg-secretary@ietf.org> writes:
>>
>> > The IESG has received a request from an individual submitter to consider
>> > the following documents:
>> >
>> > - 'Abstract Syntax Notation X (ASN.X) Representation of Encoding
>> >    Instructions for the XML Encoding Rules (XER) '
>> >    <draft-legg-xed-asd-xerei-03.txt> as a Proposed Standard
>> > - 'Encoding Instructions for the Robust XML Encoding Rules (RXER) '
>> >    <draft-legg-xed-rxer-ei-04.txt> as a Proposed Standard
>> > - 'Abstract Syntax Notation X (ASN.X) Representation of Encoding
>> >    Instructions for the Generic String Encoding Rules (GSER) '
>> >    <draft-legg-xed-asd-gserei-03.txt> as a Proposed Standard
>> > - 'Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One
>> >    (ASN.1) '
>> >    <draft-legg-xed-rxer-07.txt> as a Proposed Standard
>> > - 'Abstract Syntax Notation X (ASN.X) '
>> >    <draft-legg-xed-asd-07.txt> as a Proposed Standard
>> >
>> > The IESG plans to make a decision in the next few weeks, and solicits
>> > final comments on this action.  Please send substantive comments to the
>> > ietf@ietf.org mailing lists by 2007-02-14. Exceptionally,
>> > comments may be sent to iesg@ietf.org instead. In either case, please
>> > retain the beginning of the Subject line to allow automated sorting.
>> >
>> > The file can be obtained via
>> > http://www.ietf.org/internet-drafts/draft-legg-xed-asd-xerei-03.txt
>> > http://www.ietf.org/internet-drafts/draft-legg-xed-rxer-ei-04.txt
>> > http://www.ietf.org/internet-drafts/draft-legg-xed-asd-gserei-03.txt
>> > http://www.ietf.org/internet-drafts/draft-legg-xed-rxer-07.txt
>> > http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt
>> >
>> >
>> > IESG discussion can be tracked via
>> >
>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10739&rfc_flag=0
>>
>>_______________________________________________
>>Ietf mailing list
>>Ietf@ietf.org
>>https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf