ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] SSP - should we drop the cryptic o=. syntax for something a little more readable?

2006-02-17 09:11:07
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
        tony(_at_)att(_dot_)com

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