I just became aware of this document. I don't think that IMAP is the right place for this functionality. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Ken Murchison wrote: > Alexey Melnikov wrote: > >> Ken Murchison wrote: > >>> And what should be done for STATUS HIGHESTMODSEQ when the mailbox >>> doesn't support CONDSTORE? I assume that the server should just >>> ignore the HIGHESTMODSEQ status item, in the same way that it will >>> have to ignore the SELECT/EXAMINE CONDSTORE parameter. >> >> Right. > > Hmm, the ABNF for the STATUS response requires at least one > status-att. So what should we do for: > > a STATUS mailbox (HIGHESTMODSEQ) > > Return a HIGHESTMODSEQ of zero, or don't return * STATUS for the > mailbox? I'm assuming the latter. The latter, but I guess the document can be updated to say that the former means "modseq are not supported for the mailbox".
> 1) Leave things as they are - getting annotations will result in getting > the standard flags all over again. > > 2) Add a new STDFLAGs return option such that if a RETURN is specified, > then standard flags are only returned if STDFLAG is present as one of > the return options. If there is no return option, then the normal > behaviour occurs. > > 3) Add a new NOSTDFLAGS return option such that if specified in RETURN, > the standard flags are not returned. I AM VERY STRONGLY AGAINST 2. As Dave has already pointed out, this is a specification nightmare, giving all return options the side-effect of turning off the default STDFLAGS, and requiring that it be specified. As a document editor, I WILL NOT put it in unless the WG chair (Hi Pete!) declares consensus for it. I would be willing to add STDFLAGS if it's the case that extended LIST does NOT normally return them, and so we *always* have to ask for them explicitly. But I don't like it; I'd rather behave more like the base-doc LIST command in this regard. I will be happy to add NOSTDFLAGS (or some other such text) that EXPLICITLY tells LIST to deviate from the normal behaviour. I will point out a couple of things:(Continue reading)
On Mon, 2006-04-03 at 14:34 -0400, Barry Leiba wrote: > > 1) Leave things as they are - getting annotations will result in getting > > the standard flags all over again. > > > > 2) Add a new STDFLAGs return option such that if a RETURN is specified, > > then standard flags are only returned if STDFLAG is present as one of > > the return options. If there is no return option, then the normal > > behaviour occurs. > > > > 3) Add a new NOSTDFLAGS return option such that if specified in RETURN, > > the standard flags are not returned. .. > I would be willing to add STDFLAGS if it's the case that extended LIST > does NOT normally return them, and so we *always* have to ask for them > explicitly. But I don't like it; I'd rather behave more like the > base-doc LIST command in this regard. Actually this is how I originally read the 2) part. Never returning flags unless asked sounds good to me.. > I will be happy to add NOSTDFLAGS (or some other such text) that > EXPLICITLY tells LIST to deviate from the normal behaviour. I'm not really against this either.
The question has come up about possible extensions to what may optionally be reported by the server due to authentication conditions. Obviously, there is substantial security sensitivity here. The conditions in question are: . password will expire at such-and-such future time (or interval) . password has expired . account will expire at such-and-such future time (or interval) . account has expired . account has been disabled It is desired to include a URL that will provide more information. Currently, the only way to do this is with ALERT, but perhaps it would be useful if the client could know about some of these. Example (with both ALERT for compatibility and new response code) * NO [EXPIRED http://imap.example.com/expired] tag NO [ALERT] Your account has expired, contact the help desk Comments? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Imap-protocol mailing list(Continue reading)
On Tue Apr 4 22:15:01 2006, Mark Crispin wrote: > The conditions in question are: > . password will expire at such-and-such future time (or interval) > . password has expired > . account will expire at such-and-such future time (or interval) > . account has expired > . account has been disabled > > That last is definitely a security issue, isn't it? It'd be useful to be able to signal all the SASL codes that are in ACAP - TRANSITION-NEEDED, for instance, or AUTH-TOO-WEAK. > Example (with both ALERT for compatibility and new response code) > > * NO [EXPIRED http://imap.example.com/expired] > tag NO [ALERT] Your account has expired, contact the help desk > > Comments? I'm not convinced all clients will understand untagged responses inside an AUTHENTICATE command - I think Alexey and Corby abandoned that syntax style for the RECONNECT work a while back at least partly due to that concern. Also, I don't think that the alert is needed here - clients typically report the text of the error after a failure, so I suspect you're safe using the terminal response:(Continue reading)
Arnt Gulbrandsen wrote: >Alexey Melnikov writes: > > >>If they are all equivalent - any. >> >> >Why "any" not "all"? > > What would the client do if the server returns multiple? Pick one at random? I think the IMAP server is in a better position to decide which address to return.
RSS Feed13 | |
|---|---|
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 |
