This draft was (briefly) discussed at yesterday's meeting, and Phillip
raised the only issue: Why the handling of a list of headers is
done the way it is.
More specifically, the text currently says:
Both header and address allow the specification of more than one
header field name. If more than one header field name is specified
all the named header fields are counted in the order specified by the
header-list.
Phillip asked why the semantics weren't instead to look for the nth field in
the order the fields appear in the header.
The main reason for this is that while i see some value in being able to
determin the relative order of fields in a header, the ability to find do a a
limited sort of ordering check while looking for a single string and not being
able to determine which field matched didn't strike me as in any way useful.
And these semantics interfere with implementations like ours that use what
amounts to a hash table to quickly find headers with a given name - as everyone
knows, hashes are great at finding things quickly but sucky at retaining
ordering information.
I frankly have no idea whether or not this optimization in our implementation
is important. But when you operate in the hundreds of messages a second realm
at million mailbox sites and a significant number of mailboxes having
very substantial sieves (hundreds of tests in a single sieve are not uncommon),
it's only sensible to take any speedup you can get.
So, absent a compelling use-case for changing the semantics, I'd really prefer
to leave this as-is.
Ned