RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt

Dave Cridland <dave@cridland.net> Thu, 22 June 2006 23:30 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtYdW-00067L-A5; Thu, 22 Jun 2006 19:30:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtYdV-00067G-U1 for lemonade@ietf.org; Thu, 22 Jun 2006 19:30:57 -0400
Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtYdU-0000c8-9Q for lemonade@ietf.org; Thu, 22 Jun 2006 19:30:57 -0400
Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FtYdT-0004In-2l; Thu, 22 Jun 2006 23:30:55 +0000
Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 080CD498003; Fri, 23 Jun 2006 00:31:47 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18297-07; Fri, 23 Jun 2006 00:31:40 +0100 (BST)
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id D8438498002; Fri, 23 Jun 2006 00:31:40 +0100 (BST)
Date: Fri, 23 Jun 2006 00:30:48 +0100
Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt
References: <0FA975F2D8295A448BE3ADC16124465738ECE0@esebe199.NOE.Nokia.com>
In-Reply-To: <0FA975F2D8295A448BE3ADC16124465738ECE0@esebe199.NOE.Nokia.com>
MIME-Version: 1.0
Message-Id: <16236.1151019048.695890@peirce.dave.cridland.net>
From: Dave Cridland <dave@cridland.net>
To: "Zoltan.Ordogh@nokia.com" <Zoltan.Ordogh@nokia.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Pythagoras-IP: [217.155.137.60]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: Enhancements to Internet email to support diverse service enivronments <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>
Errors-To: lemonade-bounces@ietf.org

On Wed Jun  7 13:01:31 2006, Zoltan.Ordogh@nokia.com wrote:
> Hi all,
> A few questions/comments:
>  - Section 4.3, first paragraph. I saw some emails about 
> including/not including Compression in CONVERT. What was the 
> conclusion on this? Does the current bis reflect that agreement? 
> OMA STI does not include parameters for compressing files.
>  - Section 4.3, last paragraph. So, there will be a COMPRESS anyway?
>  - Section 4.3 general. This section is confusing. Would it be 
> possible to describe things from the compression level point of 
> view saying this is low-level, that is application-level, and that 
> is object-level compression. This is believed to be better for 
> this, that is believed to be better for that. For low-level use 
> this and that, for application-level use this and that, and for 
> object-level use this and that. This is mandatory, while that is 
> optional for the server. Clients to evaluate which is available and 
> best used according to their capabilities and the current network 
> conditions.

Alexey has tidied this up, removing the inapplicable paragraphs.


>  - Section 4.5. Normative statement missing - is it a MUST, SHOULD 
> or MAY?

It's a MUST, but expressed as a statement of fact for variety. (Note 
that CATENATE is even more extreme, dispensing with RFC2119 entirely).


>  - "required by [RFC3501]. As noted above, servers SHOULD support" 
> that note is quite far above - could we say "Section 4.3"?

Done.


>  - Section 5: "STARTTLS | Required by IMAP [RFC3501]" Are we going 
> to describe all dependencies? If not, remove, if yes, add all 
> please.

STARTTLS was historically not part of IMAP4rev1, it was mandated and 
included into RFC3501. Originally, though it was distinct, defined in 
RFC2595, and as such, I think it's a special case.


>  - Section 5: "LPROVISION, LSETPREF, LGETPREF | Section 4.4" these 
> are not described in section 4.4.

They're part of the notifications draft.


>  - Section 13, 1st bullet: double dot at the end of the paragraph.
>  - Section 13, 3nd bullet: "Notifications (server to client)" -> 
> "Server to client notifications", but: why the separation if they 
> are discussed in the same draft anyway?

Section 13 is intentionally somewhat rough notes, it will vanish. 
(It's actually section 7.7, now).

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

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