Subject: [lemonade] Comments on VFOLDER draft

From: "Alexey Melnikov" <[email-masked]>
Date: Sun, 19 Mar 2006 22:00:27 -0800

I've already commented on IMAPEXT list that some text should be borrowed
from Arnt's VIEW draft, as he seemed to to address some edge cases that
VFOLDER currently doesn't. Arnt's draft also adds a LIST-EXTENDED extension,
so that VIEW-aware clients can distinguish views from real mailboxes. I
think this might be handy for specialized clients.

Detailed comments on draft-ietf-lemonade-vfolder-00 are below:

In section 1, 2nd paragraph, second sentence:

>The search criteria specify the backing mailbox, as well as a subset IMAP
SEARCH ...

I don't think that "search criteria" can "specify the backing mailbox". At
least the SEARCH search criteria doesn't. Suggest some rewording.

Also "subset of IMAP"

Paragraph 3 in the same section:
>UIDs are preserved, and as well as the UIDVALIDITY value.

I am not sure why this restriction is required. Why enforcing it useful?

Paragraph 5:
>From the client's perspective, whether or not a mailbox is a vfolder is not
visible,

Suggest to use "virtual folder" here.

>and for all intents and purposes, it appears as any other mailbox name.
>This includes the ability for a new virtual folder to be created by using
virtual folder
>as a backing mailbox

The last sentence is insufficient. I've suggested that the new search
criteria was ANDed with the one from the virtual backing folder, however
once this was done the real mailbox is considered to be the backing one (i.e.
changed to the backing virtual folder don't affect the new view). Other
options are possible.

Last paragraph is missing reference to ANNOTATE.

In section 2:

First paragraph, second sentence: use of LPSEARCH as a term after the
LVFOLDER capability seems awkward. Did you mean LVFOLDER?

In section 3:

Description of NO response should include the two new cases described in
this section: no backing mailbox and invalid search criteria.

The text in this section is vague when saying that "an error in one of the
SEARCH argument values" causes NO response. Invalid search syntax can also
cause the BAD response.

In section 5:
 I suggest adding a comment for "psearch" non-terminal saying that search
keywords referring to mutable state are not allowed.

In section 6:
 The example that causes the BADBACKING response code is using INBOX as the
backing mailbox name, not the IMBOX.

In section 7:
 In first paragraph:
>  Modifications to mutable state (flags, annotations) have no effect on
whether
>or not messages are included virtual folders,

"included in virtual ..."

> nor do they generate events.

I am not sure what does "generate events" mean in this context. And I am not
sure why this requirement is needed.

>If a backing mailbox is deleted, then all vfolders attached to that backing
mailbox
>as deleted as well.

typo: are deleted as well

What about RENAME of the backing mailbox?

>Changes to UIDVALIDITY, UIDNEXT, and other underlying properties of

Why UIDNEXT change in the backing mailbox should always affect vfolders? If
a new message is added to the backing mailbox which doesn't show up in a
vfolder, there is no need to change the vfolder's UIDNEXT.

>the backing mailbox are reflected in all attached vfolders.

The section called "IANA Considerations" has nothing to do with IANA, as
IANA has no registry for reserved IMAP mailbox names.
I also don't like the requirement to restrict allowed vfolder names:
everything except INBOX is an implementation/deployment detail.

Section "References" should become "Normative References". Please replace
reference to RFC 2234 with RFC 4234. Please delete [P-IMAP] - it is not
referenced, at least certainly not in a normative manner.

Delete appendix A, this is a separate document now.

Regards,
Alexey
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: "Stephane H. Maes" <[email-masked]>
Date: Sun, 19 Mar 2006 22:02:01 -0800

Alexey,  Thanks  Iwill make sure not to drop any of these next time. I realize I missed some you made already in the last update.  Stephane  <!-- Converted from text/plain format  -->  
_____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Oracle. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: [email-masked] IM: shmaes (AIM/Y!/skype) or [email-masked] (MSN Messenger) or [email-masked] (Google) 
From: Alexey Melnikov [mailto:[email-masked]]  Sent: Sunday, March 19, 2006 10:00 PM To: [email-masked]; Stephane Maes Subject: Comments on VFOLDER draft I've already commented on IMAPEXT list that some text should be borrowed from Arnt's VIEW draft, as he seemed to to address some edge cases that VFOLDER currently doesn't. Arnt's draft also adds a LIST-EXTENDED extension, so that VIEW-aware clients can distinguish views from real mailboxes. I think this might be handy for specialized clients. Detailed comments on draft-ietf-lemonade-vfolder-00 are below: In section 1, 2nd paragraph, second sentence: >The search criteria specify the backing mailbox, as well as a subset IMAP SEARCH ... I don't think that "search criteria" can "specify the backing mailbox". At least the SEARCH search criteria doesn't. Suggest some rewording. Also "subset of IMAP" Paragraph 3 in the same section: >UIDs are preserved, and as well as the UIDVALIDITY value. I am not sure why this restriction is required. Why enforcing it useful? Paragraph 5: >From the client's perspective, whether or not a mailbox is a vfolder is not visible, Suggest to use "virtual folder" here. >and for all intents and purposes, it appears as any other mailbox name. >This includes the ability for a new virtual folder to be created by using virtual folder >as a backing mailbox The last sentence is insufficient. I've suggested that the new search criteria was ANDed with the one from the virtual backing folder, however once this was done the real mailbox is considered to be the backing one (i.e. changed to the backing virtual folder don't affect the new view). Other options are possible. Last paragraph is missing reference to ANNOTATE. In section 2: First paragraph, second sentence: use of LPSEARCH as a term after the LVFOLDER capability seems awkward. Did you mean LVFOLDER? In section 3: Description of NO response should include the two new cases described in this section: no backing mailbox and invalid search criteria. The text in this section is vague when saying that "an error in one of the SEARCH argument values" causes NO response. Invalid search syntax can also cause the BAD response. In section 5:I suggest adding a comment for "psearch" non-terminal saying that search keywords referring to mutable state are not allowed. In section 6:The example that causes the BADBACKING response code is using INBOX as the backing mailbox name, not the IMBOX. In section 7:In first paragraph: > Modifications to mutable state (flags, annotations) have no effect on whether >or not messages are included virtual folders, "included in virtual ..." > nor do they generate events. I am not sure what does "generate events" mean in this context. And I am not sure why this requirement is needed. >If a backing mailbox is deleted, then all vfolders attached to that backing mailbox >as deleted as well. typo: are deleted as well What about RENAME of the backing mailbox? >Changes to UIDVALIDITY, UIDNEXT, and other underlying properties of Why UIDNEXT change in the backing mailbox should always affect vfolders? If a new message is added to the backing mailbox which doesn't show up in a vfolder, there is no need to change the vfolder's UIDNEXT. >the backing mailbox are reflected in all attached vfolders. The section called "IANA Considerations" has nothing to do with IANA, as IANA has no registry for reserved IMAP mailbox names. I also don't like the requirement to restrict allowed vfolder names: everything except INBOX is an implementation/deployment detail. Section "References" should become "Normative References". Please replace reference to RFC 2234 with RFC 4234. Please delete [P-IMAP] - it is not referenced, at least certainly not in a normative manner. Delete appendix A, this is a separate document now. Regards, Alexey
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade