At 20:11 02-03-2012, John Levine wrote:
So I have two suggestions. One is to leave it as is, and make it
experimental. If it turns out the tunnels all work the same way, you
can come back and add the spec about how they work and rev it as
standards track. The other is to take out the tunnel bit and make it
standards track now, so a compliant implementation needs
priority-aware MTAs from end to end. Even if you take out the tunnel
stuff in the spec, you can still tunnel in your implementations, using
whatever non-standard ad hoc kludges you want. Since the current spec
has gaps that would need to be filled by non-standard ad hoc kludges
anyway, you haven't lost anything.
Here's the other side of the coin.
A careful review of the draft would show that the authors thought
about the idea very carefully and they have good specification and
implementation experience. The easy path would be to make this Experimental.
As John Levine mentioned above, there is an alternative to get this
on the standards track. The specification could be in three parts,
one for the SMTP extension, the second for the header field, and the
last one is about how the technologies are applied. I didn't think
about the alternative when I went through -04.
Most of the text from Section 12 would go into the third part. I
wouldn't go too much into trust; it may be easier to make use of
local policy or "use cases". If I am not mistaken, the old version
of the proposal used that approach. Bullets 2 and 3 of Section 4.2
and bullet 2 of Section 4.4 could be moved to the third part,
together with the note in bullet 1 of Section 4.3. The header
restriction for a MSA is permitted through compliance with site
policy (Section 12). Getting into S/MIME entails having to deal with
outer and inner headers. It's easier not to get into that.
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf