Harry,
HK> I think it is important to have the PRA algorithm defined in one and
HK> only one place.
definitely.
HK> Marid-submitter will still have a dependency on that
HK> algorithm whether it's specified in marid-core or a stand-alone
HK> document. Let me think about this one.
the simple way I think of it is that PRA is a clarification to
RFC2821. The rest of the spec is definition of a new capability.
It makes this specification be a customer of the marid-core
specification, rather than the reverse.
...
Again, this is about setting up specification dependencies in
a way that minimizes risk both of timing and distraction...
HK> Is your main concern here about the dependency on marid-core in this
HK> section? The only dependency is on the PRA algorithm, so this
HK> reinforces your suggestion to split that out into a separate spec.
I think that's right.
HK> However, I think it's important to give some guidance in marid-submitter
HK> to receiving systems as to how to interpret and process the SUBMITTER
HK> value.
slippery slope. in reality, doing serious justice to that goal means
replicating marid-core.
smtp options can be extremely small, discrete things. that they might
fit into some larger, more interesting system does not require that
the option document that larger thing.
HK> Equally important, we need to give _senders_ a clear
HK> understanding of what will happen to their messages when SUBMITTER is
HK> used and abused. So, I think 4.2, in some form, needs to remain.
But that is really the job of marid-core.
4.3 Transmitting to a Non-SUBMITTER Aware SMTP Server
..
This is a very big decision. I don't know whether I think it
is right or wrong, so I'm flagging it, hoping the working
group discusses it.
It makes it easier to adopt, but greatly weakens its import.
HK> I don't see how we can do this any other way. Otherwise, we're going to
HK> disrupt mail flow until everyone upgrades.
either choice has a strong and entirely legitimate basis, but it also
has a strong and serious limitation.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>