On Dec 29, 2014, at 10:13 AM, Stephen J. Turnbull wrote: > > If we change the header name, I'd want to keep X-Message-ID-Hash > > for the MM3 final release, but deprecate it. I.e. MM3 would write > > both headers. > >I'll ask some of the IETF guys what they think about that. But if you >put it in a public release, you're screwing the same kind of people >Tanstaafl was talking about. Beta testers (and I mean beta testers, >ie, people who have put the code in production even though it's not >considered a public release) have signed up for this kind of >annoyance. Random ancient Debian sysadmins haven't. > >Of course we don't want to abuse our beta testers if we can avoid it, >but I think if we don't want to maintain dual headers indefinitely, >the public release is the time to get rid of the X- version.
I'd be willing to drop it if we can get agreement on the new header, and get buy-in from at least HK (abompard) and the mail-archive.com folks. AFAIK, they are the only two "clients" of the header atm. I'm not sure if the Jeffs are still reading this list, so I've CC'd them directly. Jeffs: we are considering changing the X-Message-Hash-ID header name, at least dropping the X- prefix and possibly renaming the header. > > As for what the List-* header would be, well, if you wanted to > > include the algorithm name, to be completely accurate it would have > > to be something like > > List-Base32-Encoded-SHA1-Hash-Of-The-Message-ID. Yuck ;) > >We'd have to think somewhat carefully about how strong a hash we want to use >if we don't specify algorithm in the field name. I'm not particularly >concerned with how many bytes the header takes up. Future users can just >deal with the implied BASE32 vs. BASE85 or whatever. However, if somebody >thinks they need a stronger hash than we chose, we'll have interoperability >problems for people who receive the message off-list. Base 32 is a good trade-off between compactness and readability. > > The value of this header both serves to uniquely identify the > > message in a more regular format, and to serve as the final path > > component in the Archived-At (RFC 5064) header. So the following > > names come to mind: > > > > List-Message-ID > > List-Archive-ID > > List-Archived-At-ID > > > > suggestions welcome. > >The last two are too easily confused with Archived-At. Suggestions welcome. :) > > Right. However, when this was discussed several years ago, the > > mail-archive.com guys did some extensive data analysis on their > > vast collection of email. You'd have to go spelunking in the > > -developers archives for details, but I recall that the collision > > rate was so small as to be effectively negligible, > >Yes. The problem is that there are people out there with MUAs that >provide bogus Message-IDs (Kyle Jones's VM used to do that), and for >those people all messages after the first get dropped. As you know, I have limited tolerance for broken MUAs. Gosh, do people still use VM? :) >Note that if the server does indeed ignore the possibility of >collisions on Message-ID, then there is no need (AFAICS) for the >"thin" IArchiver to communicate with the archiver proper. Right. MM3 does not current reject messages with duplicate Message-IDs, but I think it should. I had a branch in flight that implemented this, but it caused some failures I wasn't able to resolve, and the branch bitrotted. >I don't see how it hurts to provide for the possibility of an archiver that >does check content. > > > Right, we hash (pun intended :) all this out years ago. We can > > ignore collisions, and we can do the entire calculation on the > > server side, using Message-ID as the sole input. I think the only > > issue that's worth reopening is the name of the header. > >Well, that's true for *us*. The folks at the IETF don't have a habit >of leaving well enough alone, though. ;-) Right, so let's do what *we* think is right, right now, and let the committee take 10 years to define a standard. ;) Cheers, -Barry
pgpQ2MsKTxb0o.pgp
Description: OpenPGP digital signature
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
