I've seen 'in the wild' keywords such as $Label1, $Label2 etc Since I'm in the process of adding keyword support and want to have a fixed set of 'labels' that a user can define I'm interested in knowing whether this is something that should be 'standardised' behaviour to promote interop between clients. -- -- Cyrus Daboo
On Sun, 06 Apr 2003 23:02:24 -0400, Cyrus Daboo wrote:
> I've seen 'in the wild' keywords such as $Label1, $Label2 etc Since I'm in
> the process of adding keyword support and want to have a fixed set of
> 'labels' that a user can define
^^^^ client
I think that my correction is important.
If you want "labels" that a user can defined, that's keywords.
What you are asking about is a set of fixed names which has a different
meaning on a per-client basis.
> I'm interested in knowing whether this is
> something that should be 'standardised' behaviour to promote interop
> between clients.
I certainly hope not. But I'm not going to oppose it either.
I am somewhat perplexed as to how this would be useful; but I don't see
particular harm either.
Mark Crispin wrote: > On Sun, 06 Apr 2003 23:02:24 -0400, Cyrus Daboo wrote: > > I've seen 'in the wild' keywords such as $Label1, $Label2 etc Since I'm in > > the process of adding keyword support and want to have a fixed set of > > 'labels' that a user can define > ^^^^ client > > I think that my correction is important. > > If you want "labels" that a user can defined, that's keywords. > > What you are asking about is a set of fixed names which has a different > meaning on a per-client basis. I agree. Regarding the original question: I think we should standardize used client labels, but $Label1/$Label2/... should not be standardized, because they have no associated meaning. I've only seen $Label1/... being implemented in Mozilla. Mozilla allows a user to set on a message one of 5 mutually exclusive labels and a user can modify the meaning of these labels (i.e. their text description is editable). This is wrong, as there is no way to share what $Label1 means for different clients, and it is possible to have unpredictable results as two Mozillas can be configured differently. Cheers,(Continue reading)
Alexey has submitted the latest version of conditional store as a WG draft. We've all had plenty of time with it, so this is a WG last call on it. Please see: http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-00.txt Please post affirmative comments as well as any problems you might have. I'd like to submit this for IETF last call ASAP. pr -- -- Pete Resnick <mailto:presnick <at> qualcomm.com> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Comments:
A document in Last Call should not have open issues. Resolve them one way
or another. I recommend that:
. it NOT be required that conditional STORE be atomic across the message
set
. STORE should NEVER reply NO; instead, the untagged FETCH response
should be relied upon to indicate what happened
I disapprove of the idea of NO with the MODIFIED status code. This
introduces, for the first time, an instance where the server replied NO
but something happened anyway. The command succeeded and did what was
requested; therefore OK should be returned (with the MODIFIED status
code).
Otherwise, the document seems technically fine to me. I think that we
should be kind to the RFC Editor and edit it into a shape that's somewhat
closer to publication status.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
One last thing... I know that this is rather late, but is there a recommended way for a server which has CONDSTORE to operate with a mail store that does not support it (e.g. always return 0)? I could offer CONDSTORE much faster in my server if I don't have to support in in all possible mailbox formats. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
Hi Mark, --On Friday, April 11, 2003 1:58 PM -0700 Mark Crispin <MRC <at> cac.washington.edu> wrote: | I know that this is rather late, but is there a recommended way for a | server which has CONDSTORE to operate with a mail store that does not | support it (e.g. always return 0)? | | I could offer CONDSTORE much faster in my server if I don't have to | support in in all possible mailbox formats. I guess that could be done by either allowing 0 or having an untagged response as part of SELECT to indicate CONDSTORE is not supported on the mailbox being selected, even though the capability is present. The later would be better because clients could then not use the extended commands for that mailbox. Perhaps the HIGHESTMODSEQ response with value '0' could be used as an indication of this? -- -- Cyrus Daboo
You need to change the annotation entry names to exclude the "/message" prefix. We agreed to eliminate the /message and /body entry name prefixes at the last meeting. I'm hoping to get an updated annotation document out in the next week with that and other changes. -- -- Cyrus Daboo
Cyrus Daboo wrote: > Hi Mark, > > --On Friday, April 11, 2003 1:58 PM -0700 Mark Crispin > <MRC <at> cac.washington.edu> wrote: > > | I know that this is rather late, but is there a recommended way for a > | server which has CONDSTORE to operate with a mail store that does not > | support it (e.g. always return 0)? > | > | I could offer CONDSTORE much faster in my server if I don't have to > | support in in all possible mailbox formats. > > I guess that could be done by either allowing 0 or having an untagged > response as part of SELECT to indicate CONDSTORE is not supported on the > mailbox being selected, even though the capability is present. The later > would be better because clients could then not use the extended commands > for that mailbox. Perhaps the HIGHESTMODSEQ response with value '0' could > be used as an indication of this? I have no problems with the last suggested change (i.e. HIGHESTMODSEQ with 0). Alternatively, we can say that if no HIGHESTMODSEQ is returned on SELECT, then CONDSTORE is not supported for the mailbox? This is probably better. Anybody else? Alexey(Continue reading)
The formal syntax for 'entry-name' should be simply defined as:
entry-name = string
to fall in line with ANNOTATE. There should be a comment/reference to the
annotate spec at that point. That will also allow you to remove the comment
about escape rules at that point.
Also, could be use "priv" instead of "private" for entry-type-resp just to
fall in line with the suffixes that ANNOTATE uses?
--
--
Cyrus Daboo
RSS Feed22 | |
|---|---|
21 | |
27 | |
8 | |
17 | |
10 | |
60 | |
6 | |
48 | |
113 | |
7 | |
16 | |
10 | |
2 | |
1 | |
15 | |
2 | |
2 | |
1 | |
2 | |
3 | |
52 | |
1 | |
5 | |
1 | |
10 | |
19 | |
2 | |
4 | |
30 | |
1 | |
12 | |
96 | |
39 | |
6 | |
30 | |
48 | |
6 | |
25 | |
61 | |
1 | |
15 | |
10 | |
68 | |
42 | |
1 | |
9 | |
9 | |
181 | |
26 | |
72 | |
63 | |
2 | |
7 | |
27 | |
43 | |
87 | |
39 | |
87 | |
69 | |
102 | |
55 | |
54 | |
35 | |
28 | |
87 | |
111 | |
18 | |
68 | |
100 | |
43 | |
18 | |
109 | |
74 | |
34 | |
56 | |
21 | |
28 | |
67 | |
35 | |
3 | |
29 | |
19 | |
31 | |
144 | |
57 | |
150 | |
17 | |
9 | |
40 | |
133 | |
24 | |
42 | |
31 | |
31 | |
36 | |
3 | |
25 | |
7 | |
5 | |
88 | |
22 | |
32 | |
30 | |
17 | |
14 | |
80 | |
19 | |
19 | |
3 | |
23 | |
72 | |
15 | |
9 | |
12 | |
34 | |
55 | |
26 | |
16 | |
63 | |
37 | |
9 | |
84 | |
9 | |
32 | |
21 | |
5 | |
26 | |
21 | |
1 | |
3 | |
26 | |
19 | |
32 | |
28 | |
30 | |
1 | |
7 | |
1 | |
2 | |
5 | |
1 | |
10 |
