I'd like to do a more explicit consensus call now to nail this down. I've tried to identify the major points of attraction rather than every variant, to see where people are leaning. Please reply with one of these options, a variant, and explanation if you like:
A) auth-header to not require any feature advertising or auto-configuration B) auth-header to normatively RECOMMEND some kind of feature advertising C) auth-header to normatively REQUIRE some kind of feature advertising Separately, the unspecified feature advertising or auto-conf should be (choose one or more): 1) IMAP Capabilities advertising 2) E/SMTP capabilities 3) IMAP annotations 4) Something else 5) Nothing Note that I've left document organization out of the poll. If people feel strongly about that they can argue about it. Lisa On Sat, Oct 11, 2008 at 10:13 AM, Alexey Melnikov <[EMAIL PROTECTED] > wrote: > Hi Murray, > Some quick comments about your IMAP proposal that uses ANNOTATE. > > >3. IMAP Server Implementation > > > > An [IMAP] server conforming to this specification MUST implement > > [ANNOTATE] and MUST report these annotations to the client if they > > are attached to the message(s) being requested. > > > > > The second MUST: I am not sure what you are trying to say here. If you > are saying that the new annotations must be reported whenever the > corresponding message body is send (or similar), then that is not how > the ANNOTATE extension works. > [...] > > >5.1. Formal Definition > > > > The content of the annotation, as defined using [ABNF], is as > > follows: > > > > authres = 1*( version ":" authserv-id ":" methodspec > > ":" propspec ) > > ; relays a single unit of authentication results > > ; information > > > > > Are you trying to list multiple authresults here? I think you are > missing some delimiter between individual values, e.g. SP. > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html >
