Re: [lemonade] I-D ACTION:draft-ietf-lemonade-futuredelivery-02.txt
Randall Gellens <randy@qualcomm.com> Thu, 15 September 2005 21:34 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG1N2-00038b-Np; Thu, 15 Sep 2005 17:34:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG1N1-00038T-HH for lemonade@megatron.ietf.org; Thu, 15 Sep 2005 17:34:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11728 for <lemonade@ietf.org>; Thu, 15 Sep 2005 17:34:12 -0400 (EDT)
Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG1Rp-0007b6-Fn for lemonade@ietf.org; Thu, 15 Sep 2005 17:39:18 -0400
Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8FLXq7S013490; Thu, 15 Sep 2005 14:33:53 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p07000c14bf4e4a021425@[129.46.172.15]>
In-Reply-To: <E1E5TvG-0001wO-4E@newodin.ietf.org>
References: <E1E5TvG-0001wO-4E@newodin.ietf.org>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook? Upgrade to Eudora: <http://www.eudora.com>
Date: Thu, 15 Sep 2005 14:33:43 -0700
To: g.a.white@comcast.net, GregV@ieee.org
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-futuredelivery-02.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe>
Sender: lemonade-bounces@ietf.org
Errors-To: lemonade-bounces@ietf.org
I think you should reference draft-gellens-submit-bis-02.txt instead of RFC 2476, since submit-bis is in the RFC editor's queue. It's quite a nit, but if you do publish a revision prior to approval, I'd suggest changing "voted" to "agreed" in section 13.1. In section 4.1.1, the first two requirements seem a little silly to state. In 4.1.2.6, I wonder if perhaps it might be more clear to say "exceeds" rather than "strictly greater than". We seem to like using "strictly" in situations where I think our meaning isn't clear ("strictly increasing", to use an example from a different context). My assumption is that in this case, "strictly greater than" means just "greater than", and is used to exclude equality, which I don't think would be implied anyway. This also applies to 4.3.1.1: "the value of the future-delivery-interval-param MUST be strictly less than the value of the accompanying by-time parameter" should perhaps be "the value of the accompanying by-time parameter MUST exceed the value of the future-delivery-interval-param". (I like section 4.2.1.1 -- it makes me think of a server that implements "whenever Joe sends a message, hold it for three days and then bounce it") In 4.2.2.1 and 4.2.2.2, I think there is a potential ambiguity in "If an MSA generates a DSN for a message that includes a Future Delivery request" -- it could be read that the DSN has a future delivery request. Perhaps, just to be sure, this could be reworded slightly, maybe just change "that includes" to "which included" or "which used"; the use of past tense might make this more clear. In 4.3, there is a blank line in the middle of the first paragraph. In 5.2, I'm not sure that it is proper to say "An MSA's future-delivery storage SHOULD be subject to a per-user quota" -- I don't think we can justify the SHOULD on interoperability grounds, and the text already points out to implementors that there is a security consideration in managing storage. How the implementation decides to protect against this risk should be up to it. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- ... But as records of courts and justice are admissible, it can easily be proved that powerful and malevolent magicians once existed and were a scourge to mankind. The evidence (including confession) upon which certain women were convicted of witchcraft and executed was without a flaw; it is still unimpeachable. The judges' decisions based on it were sound in logic and in law. Nothing in any existing court was ever more thoroughly proved than the charges of witchcraft and sorcery for which so many suffered death. If there were no witches, human testimony and human reason are alike destitute of value. --Ambrose Bierce, "The Devil's Dictionary" _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade
- [lemonade] I-D ACTION:draft-ietf-lemonade-futured… Internet-Drafts
- Re: [lemonade] I-D ACTION:draft-ietf-lemonade-fut… Mark Crispin
- Re: [lemonade] I-D ACTION:draft-ietf-lemonade-fut… Randall Gellens