The obvious problem is that there's no way to tell if the in-line data
is real without making another transaction back to the sender's domain
to check. If we have to use a separate TCP session to fetch a
possible cachable chunk of XML, the right way to do that is with http
and just fetch the policy document. It's defined, it's standard, it's
debugged, it's available, and it works.
I agree with you in general (and with Hadmut), but would point out that
http is also primarily one-key lookup protocol (which has been extended a
lot by means of cgi parameters) and retreiving entire policy document is
not the best idea if we're talking about it being so large that its
better off at the http server.
You can encode any query you want into a URL. I don't see that as a
problem. You want to work in the mailbox, time of day, number of
messages, phase of moon, just define some conventions to map the
parameters you want into the URL.
The best (in my opionion) is to actually work on specifications on new
policy document such that it can be deployed over existing pre-built
I entirely agree. That's why I keep saying http. Do experiments with
http, then if we find that we're looking up lots of tiny documents, and
they'd fit into single packets, and the lookup is a bottleneck, then it'd
makes sense to consider some lighter weight protocol.
Until then, I don't see any point in defining a policy protocol until we
have some experience defining and using policy documents. At this point
we don't even know who'll be publishing them and how a mail recipient will
decide who to ask.
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.