RE: Children flags, RFC3348.
On 13 Jan 2004 at 10:36, Mark Crispin wrote: > > H.. Can we then have a \Subscribed flag too? > > That would require that all subscribed mailboxes exist. Why? To me it simply suggests that all existing mailboxes that are subscribed could report that fact via LIST. Since I'm doing a lot of work in correcting the way my client handles folder listing at the moment, issues like this are kind of uppermost in my mind... I've found that I'm using two or three approaches to handling folder lists, some involing LIST and some involving LSUB; for the former, I can see that it would actually be quite useful to know that a folder was subscribed when I LISTed it - as it stands now, I often need to issue both commands I rather like this idea, in fact. Cheers! -- David -- -- David Harris -+- Pegasus Mail -- Box 5451, Dunedin, New Zealand | e-mail: [EMAIL PROTECTED] Phone: +64 3 453-6880 | Fax: +64 3 453-6612 Quote for the day: "If all the girls at the Yale Prom were laid end-to-end I wouldn't be at all surprised." -- Dorothy Parker
RE: Children flags, RFC3348.
On Tue, 2004-01-13 at 10:36 -0800, Mark Crispin wrote: > On Tue, 13 Jan 2004, David Woodhouse wrote: > > H.. Can we then have a \Subscribed flag too? > > That would require that all subscribed mailboxes exist. Not really. > > Or is there another way of finding out which folders are subscribed > > other than separately issuing LIST and LSUB commands? ...I should have said LIST and LIST (SUBSCRIBED) here, I suspect; since that's what I actually want. -- dwmw2
RE: Children flags, RFC3348.
On Tue, 13 Jan 2004, David Woodhouse wrote: > H.. Can we then have a \Subscribed flag too? That would require that all subscribed mailboxes exist. > Or is there another way of finding out which folders are subscribed > other than separately issuing LIST and LSUB commands? No. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
RE: Children flags, RFC3348.
On Tue, 2004-01-06 at 07:20 -0800, Larry Osterman wrote: > It turns out that the documentation for LIST explicitly says that you > can have whatever flags you wanted (read the spec carefully) so there > was no need for a new variant of LIST. H.. Can we then have a \Subscribed flag too? Or is there another way of finding out which folders are subscribed other than separately issuing LIST and LSUB commands? -- dwmw2
RE: Children flags, RFC3348.
Because at the first IMC face-to-face, a number of client authors said: "Hey, it would be REALLY nice if you added this feature to the protocol", Mike Gharns said "Sure, I'll write it up", and I said "Ok, I'll put it in". So we did. And a couple of people added support for it and. It turns out that the documentation for LIST explicitly says that you can have whatever flags you wanted (read the spec carefully) so there was no need for a new variant of LIST. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David Harris > Sent: Saturday, January 03, 2004 2:52 PM > To: [EMAIL PROTECTED] > Subject: Children flags, RFC3348. > > OK, Arnt Gulbransen has pointed me at RFC3348, which covers > the CHILDREN extension (thanks Arnt). > > What I want to know now is "why is the Exchange server using > this extension?". > > Consider this text from RFC3501 section 7.2.1 (CAPABILITY > response, page 67 in my copy): > > -- Cut here >Other capability names indicate that the server supports an >extension, revision, or amendment to the IMAP4rev1 protocol. >Server responses MUST conform to this document until the client >issues a command that uses the associated capability. > -- Cut here > > Now, I have issued *no* command other than LIST in this > session: am I wrong in thinking that the Exchange server is > behaving improperly by sending LIST responses that contain > HasChildren and HasNoChildren flags in them? Surely I should > need to issue the command "CHILDREN" > (or whatever) before this extension is enabled? RFC3348 does > not appear to me to be a formal revision of RFC3501 (or of > 2060, for that > matter) - its status is "informational". > > I don't want to sound anal about this, but it seems to me > that a major aspect of IMAP has always been ensuring > interoperability, and injudicious use of extensions in this > manner is not conducive to that. In this case it's probably > relatively harmless, but I can think of plenty of situations > where it would not be. > > Or am I simply misunderstanding this issue? Is it in fact > legal for a server to issue any response it wants in this case? > > Cheers! > > -- David -- > > -- David Harris -+- Pegasus Mail > -- > Box 5451, Dunedin, New Zealand | e-mail: [EMAIL PROTECTED] >Phone: +64 3 453-6880 | Fax: +64 3 453-6612 > > Thought for the day: > Erotic (adj): using a feather as a sex aid. > Kinky (adj): using the whole duck. > > > > -- > - > For information about this mailing list, and its archives, see: > http://www.washington.edu/imap/imap-list.html > - > >
Re: Children flags, RFC3348.
PS: I think that the requirement for standards-track for list-extension is new in 3501, so it can be argued that 3348 is grandfathered. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Children flags, RFC3348.
On Sun, 4 Jan 2004, David Harris wrote: > There is nothing about RFC3348 that makes it either a standard or a > standards-track revision of RFC3501 - or even of RFC2060. Its status is > nothing more than informational. I forget now why RFC 3348 was informational. Perhaps it was because CHILDREN was not client-triggered. Anyway, listext will probably supercede RFC 3348 and the issue will eventually become moot. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Children flags, RFC3348.
On 3 Jan 2004 at 16:55, Mark Crispin wrote: > > What I want to know now is "why is the Exchange server using this > > extension?". > > It is "not incorrect" for Exchange to send it without client permission. > flag-extension is part of the rule of mbx-list-flags (via mbx-list-oflag) > in RFC 3501, thus a server *may* send unilaterally and a client is obliged > to handle it. But what about this text in the RFC3501 BNF? -- Cut here flag-extension = "\" atom ; Future expansion. Client implementations ; MUST accept flag-extension flags. Server ; implementations MUST NOT generate ; flag-extension flags except as defined by ; future standard or standards-track ; revisions of this specification. -- Cut here There is nothing about RFC3348 that makes it either a standard or a standards-track revision of RFC3501 - or even of RFC2060. Its status is nothing more than informational. > > Or am I simply misunderstanding this issue? Is it in fact legal for a > > server to issue any response it wants in this case? > > Yes, you misunderstood; What have I misunderstood, then? That text appears to be quite unambiguous to me. Or has the status of RFC3348 changed? Cheers! -- David -- -- David Harris -+- Pegasus Mail -- Box 5451, Dunedin, New Zealand | e-mail: [EMAIL PROTECTED] Phone: +64 3 453-6880 | Fax: +64 3 453-6612 Thought for the day: When the going gets tough, the tough go shopping.
Re: Children flags, RFC3348.
On Sun, 4 Jan 2004, David Harris wrote: > What I want to know now is "why is the Exchange server using this > extension?". It is "not incorrect" for Exchange to send it without client permission. flag-extension is part of the rule of mbx-list-flags (via mbx-list-oflag) in RFC 3501, thus a server *may* send unilaterally and a client is obliged to handle it. Note that there are other places in the base specification which permit the server to do unilateral extended things without client permission. The most notable examples are system flags (another flag-extension) and BODYSTRUCTURE (body-extension). Response codes are arguably another example. More to the point, though that's what RFC 3348 requires; there is no client-based trigger for the CHILDREN extension. RFC 3348 choose to go this route rather than have a separate command to enable it. I did not like this for a different reason: \HasChildren and \HasNoChildren are expensive to calculate in a UNIX filesystem based server, and thus I would not want to do the work unless I knew that the client cared. This is one of the things that has lead to the listext work in IMAPEXT. Clearly we did not want to add CLIST and CLSUB and CRLIST and CRLSUB, but that is where we were heading if we insist upon a client trigger for CHILDREN. > Or am I simply misunderstanding this issue? Is it in fact legal for a > server to issue any response it wants in this case? Yes, you misunderstood; but no, it isn't legal for the server to issue just "any response it wants". However, it should be noted that there *is* some extensibility in certain server responses that the base specification requires all clients to accept, even if it doesn't say what those responses mean. The idea is that such things as flags and BODYSTRUCTURE and response codes can be extended and a compliant client will just ignore the extended data rather than barfing. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
