Re: Discussion of Internet-Draft for SMTP priorities

Hello Michael,

I would like to echo Janet's request of putting in place a  
prioritization field that is more extendable so that various sets of  
users could rely on different priority structures/values, but more  
importantly, different associated policies.  The one major headache  
is that if you go down this road, I think your draft will require  
some significant changes.

Janet mentioned RFC4412, whose structure is a string based BNF  
representation.  If you would prefer a strictly numeric  
representation for the NameSpace.Value tuple first mentioned in  
RFC4412, you should look at NSIS QSPEC draft (which I believe is  
under WG last call)
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt.  In  
either case, you can leverage previous work and choose to do so  
either in alphanumeric or strictly numeric form and not have to worry  
about specifying your own IANA registry.

One minor point involves Section 4.1  You mention using the ToS field  
as a means of supporting expedited transfer.  Its probably best to  
update that text with RFC-3168, which deprecates ToS (and precedence  
fields) in favor of the Differentiated Services field.

Also, I would disagree with your statement that your proposed field  
does not "raise any security issues not already endemic in electronic  
mail".  Currently, with FIFO based system we have a system where  
everyone experiences a form of best effort in obtaining MTA  
resources.  But with your proposed extension, one introduces a case  
where email labeled as low priority can be indefinitely starved of  
resources.  In some systems/domains, this may be desired.  In others,  
one may want a more weighted round robin servicing so that priorities  
correlate to the weights, but eventually, all message queues would be  
serviced.  Outside of that, it would seem desirable for your draft to  
at least advocate some measures of security like S/MIME for header  
protection (rfc-3851), and possibly the use of AUTH.

Finally, in section 6.5.3, you state some specific delivery time  
constraints.  I'm curious as to where you came up with those numbers  
-- it would probably be helpful to add some context.  Some deployed  
underlying HF and ULF systems would have a hard time meeting your  
constraints depending on message size.  My personal feeling is that  
it may be best to move text like that and 4.1 into an appendix

outside of that, its a nice document for discussion

-ken