Is there any reason that tag=value syntax does follow the
parameter=value
syntax defined in RFC-2045? I.e. Are implementors required to
implement another "tag" parsing scheme?
Indeed. We really don't need another of these if we can avoid it, but I'm
not
sure we can avoid it...
Due to political or technical reasons? :-)
Er, yes? ;-)
I'm dubious about it being appropriate to apply here. I think RFC 2231 goes
too
far and is too difficult to implement.
I agree with the implementation comment. I've always been curious
of what softare actually supports it. I wrote Perl code years
ago to parse RFC-2184 parameter extensions, but never incorporated
it into anything since I have never seen its use in the wild.
I've seen several implementations, but the overall implementation quality
in several cases hasn't been good.
FWIW, I've always been hesitant to try and move to draft with this one.
You touch upon the reason you co-authored RFC-2231. RFC-2047 does
not cover parameter value cases. Even though I have seen cases
where mail software will actually use 2047 encoded words in
a parameter value (e.g. filename parameter in Content-Disposition),
this is non-standard.
Only the encoding part would be useful here in any case. The thought of
supporting different charsets in DKIM is too horrible to comtemplate...
- For the "t=" tag, why not use ISO date/time format. For example:
20050714T045532
A reference to RFC 3339 would seem to be in order here.
The RFC definitely gives weight to use the format.
Note, Meta-Signatures has adopted a slight variant where the "T"
is dropped. Apparently, there is a desire to have the date to
be only an integer, but I am not clear on the full reasons for this.
The T is kinda sorta useful as a visual aid in breaking the field up. Aside
from that it is pretty much a wasted byte.
- "z=" is a mess, and can eventually lead a DKIM field that is
longer than 988 octets (RFC-2822 limit).
...
Well, I like the implicatio nthat the sending MTA should do it. However,
exactly when that MTA should do it is going to be a tricky matter. I for
one am
mulling this one over big-time in considering how I'm going to implement
it.
I am not convinced (yet) that signing must be done at the border MTA.
Perhaps not at a border MTA, but definitely by some MTA. Getting MUAs to
update is very difficult.
We need to face the facts of life here, and rewriting is one of those
facts.
I also don't think the complexity of saved headers is worth it, and that
means MUA-level signing is simply not going to work in many cases.
I think such a policy can cause a power-shift in the Internet. Now,
there are some practical things ISPs can do so MUA-based signing is
not a problem. For example, when a customer submits a message for
delivery (and it is signed), the ISP knows to not apply any re-write
rules or other modifications that can invalidate the signature.
My problem is that every indication I see is that ISPs are heading en masse in
the opposite direction. More and more stuff is being done as part of the ISP.
If you want a specific example, take a look at the forward-without-download
specifications the LEMONADE WG has produced and which just entered IETF last
call. Good luck having the client sign messages constructed this way.
I'll also add that we're seeing lots of interest in this stuff from
several very large ISPs.
For organizations that like to normalize all addresses
(e.g. earl(AT)machine.earlhood.com => earl(AT)earlhood.com),
they can implement policies for their users that signing is done
at the MTA level, or do other software configurations to miminze
re-writing.
I definitely see a day that if signing of email is a requirement
for message delivery, the signing process should not be in the
control of a few large, powerful entities.
Well, in theory nothing prevents you from running your own MTA. Although the
day may come when port 25 blocking is the rule, not the exception, you have no
choice but to send your mail to the ISP's mail server, and those servers will
as a matter of course do all sorts of message mangling.
Or, to put it another way, I think signing requirements are largely orthogonal
to whether or not control of email ends up in thehands of a few large
corporations.
Ned