[approved] RFC 5064 Archived-At header

[Barry Warsaw-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello MHonArc and Mailman developers.

RFC 5064 describes the Archived-At header, which is used to point  
directly to the archived version of a mailing list mail message.  The  
value of this header could also be used in a message body footer, such  
as the type that Mailman typically adds to its list copy of the  
message.  Supporting this would be a big improvement in usability for  
mailing lists and is an often requested feature of Mailman.

We have been having some off-list discussions recently between Jeff  
Marshall and Jeff Breidenbach of the Mail-Archive.com, Earl Hood of  
the MHonArc project and myself on approaches that would provide for  
support of RFC 5064 Archived-At headers.  The RFC itself is agnostic  
on how to calculate the value of this header, but it does provide some  
suggestions.  On the mailman-developers mailing list a while ago we  
discussed several ways of calculating this header, and in our private  
discussions, we've refined our thoughts.  We're now at something of an  
impasse, where the specific approach requires us to make some trade-
offs between implementation choices and usability.  It's now time to  
get your feedback.

I've just updated the current proposal on the Mailman wiki:

http://wiki.list.org/x/yQAM

See specifically the Open Issues section.  The most straight-forward  
way to implement this leads to long, unusable (in our opinion) urls.  
Shortening the urls would require quite a bit of additional  
implementation complexity.  What to do?

It's time to open this up to your ideas, but let me say that from  
Mailman(3)'s perspective, the exact algorithm probably doesn't matter  
much.  I have a bzr branch that implements the interfaces and  
infrastructure for archiver plugins, so if MHonArc, Pipermail, and  
Mail-Archive.com all chose different algorithms, we can fairly easily  
write a different plugin for each.  Still, it would be good to  
standardize on a usable, implementable approach.

I invite you to read the wiki page, and comment either there or as a  
follow up to this message.  I am not on the mhonarc-dev mailing list.

Cheers,
- -Barry
P.S. mhonarc-devs: I apologize in advance for the replybot on my email  
address.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkhsXCIACgkQ2YZpQepbvXFvNwCgg6jS/6NgmwYMa1W+9786Qd63
d00AoLJ99UEbKmvoBRUGbVi+B+PHJZEk
=Lzo8
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To sign-off this list, send email to majordomo@... with the
message text UNSUBSCRIBE MHONARC-DEV

[Earl Hood]

On July 3, 2008 at 00:57, Barry Warsaw wrote:

> I've just updated the current proposal on the Mailman wiki:
>
> http://wiki.list.org/x/yQAM
>
> See specifically the Open Issues section.  The most straight-forward  
> way to implement this leads to long, unusable (in our opinion) urls.  
> Shortening the urls would require quite a bit of additional  
> implementation complexity.  What to do?

Quick editorial comment: in the "Open issues" section, you write:

  "... Mail-Archive.com uses MHonArc which requires the use of the
  list name in the url."

This is misleading wrt mhonarc.  Mhonarc imposes no requirement on
how an archive is structured on the file system from a pathname
perspective.  The convention is something imposed by the user.


As for "readable URLs", I still think it may be a bogus concern.
Usability testing would have to be done to verify if this concern
is real.

Wrt this context, it seems most will "click" on the URL in the mail
message, or copy-n-paste it.

And even then, I wonder how much the link will actually get used.
Will someone provide some real use case scenarios of how the
archived-at URL gets used by a message receipient.  If I have
the message locally, do I care where it is archived?

One reasonable case I can think of is if a receipient wants
to tell others about the message, and instead of forwarding
the message they got, they just send a URL to it, which would
allows others to following subsequent follow-ups if they are
not subscribed to the list.

Or, they bookmark the link so they can always go back to the
message w/o having to archive in their local MUA.

Either scenario implies the user can either do a couple of clicks
or just copy-n-paste the URL to their bookmark manager.

This implies the archive-at URL is mainly for bookmarking purposes.  I.e.
I go to the archive and read some messages (or got their via a search).
I see a message of interest, and want to bookmark it so I can go back
to it directly.

--ewh

P.S. When time permits, I will look into mhonarc to see if it can
be changed so the filenames it uses for messages can be based on
Stable URL since stable filenames has been a problem for mhonarc.

--
Earl Hood, <earl@...>
Web: <http://www.earlhood.com/>
PGP Public Key: <http://www.earlhood.com/gpgpubkey.txt>

---------------------------------------------------------------------
To sign-off this list, send email to majordomo@... with the
message text UNSUBSCRIBE MHONARC-DEV

[Jeff Breidenbach]

>Will someone provide some real use case scenarios of how the
>archived-at URL gets used by a message receipient.  If I have
>the message locally, do I care where it is archived?

It's handy if you are writing a blog. For example, Linux Weekly
News reports on the Linux Kernel mailing list. They quote
particular messages, and provide an archival link. This lets readers
examine the (possibly active) thread.

http://lwn.net/Articles/286910/
http://lwn.net/Articles/287490/

[Earl Hood]

On July 3, 2008 at 10:52, Barry Warsaw wrote:

> You may be right that the readability argument is specious. It may be that
> cut-n-paste is the overwhelming use case for archived-at. Does that mean
> you'd argue for the slightly shorter base64 encoding of the hash?

I have no strong feelings on this matter, but base64 does allow
for the '/' character, which can be a problem for usage within
URLs since it is a path separator.

That alone may make base32 the better choice, even though it
will lead to a longer string.

--ewh

---------------------------------------------------------------------
To sign-off this list, send email to majordomo@... with the
message text UNSUBSCRIBE MHONARC-DEV

[Earl Hood]

On July 7, 2008 at 11:43, Barry Warsaw wrote:

> Actually RFC 3548 defines a "url safe" base64 alphabet which substitutes -
> and _ for + and /. Python's base64 library supports this and I propose
> using this alternative alphabet if we go with base64.

I did not know there was an RFC for this.

The RFC is marked as "Informational", so how widely used is
the URL-safe base64 encoding used?

Nothing is currently listed in the IETF assignments for this
type of encoding:
http://www.iana.org/assignments/transfer-encodings

I have no problems going with it, as long as it is documented.
However, from a usability perspective (possibly), the use
of understrike can be a problem.

For example, links are normally rendered with an underline, and
this rendering behavior can "hide" an understrike character, making
the URL appear to have a space in it.

--ewh

---------------------------------------------------------------------
To sign-off this list, send email to majordomo@... with the
message text UNSUBSCRIBE MHONARC-DEV