Lisa Dusseault wrote:
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
I am in favour of B, but I want it to be described informatively with
examples. (I.e. I think having a SHOULD would be a mistake)
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.
2) for auto-configuration.
I am still deciding between 1) and 3) on IMAP side. If the information
can be different for different messages, then a new IMAP capability is a
wrong way to do this. In this case IMAP per-message annotations are a
better fit, but I do have some concerns about deployability.
Lisa
On Sat, Oct 11, 2008 at 10:13 AM, Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com
<mailto:alexey(_dot_)melnikov(_at_)isode(_dot_)com>> 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
------------------------------------------------------------------------
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html