Who said that we'd have to replace the current single character tags with other single character tags?
There were a couple of threads last November about changing o= to use words and splitting out the semantics around the various semantic axes that are covered by the value (sending mail, signature presence, 3rd party signatures, redirect). One message that I wrote had a table, showing what a couple possible syntaxes might be for o= (http://mipassoc.org/pipermail/ietf-dkim/2005q4/001307.html, slightly modified here): o=-signature,-3ps signature=never,3ps=never ?/WEAK o=~signature,-3ps signature=optional,3ps=never ~/NEUTRAL o=~signature,+3ps signature=optional,3ps=allowed !/EXCLUSIVE o=+signature,-3ps signature=always,3ps=never -/STRONG o=+signature,+3ps signature=always,3ps=allowed ./NEVER o=nomail nomail ^/USER o=user checkuser William Leibzon also had suggestions along the same lines (http://mipassoc.org/pipermail/ietf-dkim/2005q4/001306.html): > 1. Signature required/optional: > sig=MUST/SHOULD/NEVER/USER (sig=STRONG/NEUTRAL/NEVER) > 2. 3rd parties allowed/not > 3ps=ALLOW/DENY/USER > > (Or if you like o=STRONG/3PS | o=NEUTRAL/NO3PS | o=USER/USER) Hector Santos had several suggestions for additional values in the 3ps space. (http://mipassoc.org/pipermail/ietf-dkim/2005q4/001318.html): > signature=always, 3PS=IGNORE -- Keep Original, don't strip, resign > signature=always, 3PS=APPEND -- Append, don't strip or replace. > signature=always, 3PS=RESIGN -- strip and replace. Tony Hansen [EMAIL PROTECTED] Michael Thomas wrote: > For two reasons: > > 1) With my developers hat on, I couldn't really care the least: > if you have to look them up, you probably need to look up the > other single character tags too. This is just a matter of being > familiar with the spec, and h, z, b, m etc are all equally > opaque IMO. > > 2) I'm guessing that we will utterly fail to have a single word that > describes the rich semeantics of the policy attached to whatever > symbol we choose. Witness this latest brouhaha with "exclusive" > which is not even part of the current draft. An abstract symbol > which has no baggage of its own and is, in fact, just a pointer > to the normative text seems like a better way to avoid > misinterpretation. _______________________________________________ NOTE WELL: This list operates according to http://dkim.org/ietf-list-rules.html
