threaded mailto: response alternatives

Jose,

I understand that some people in the W3C are reluctant to
implement the Hoffman Draft mailto: parameter syntax in the W3C
archives because there is as yet only partial implementation
among browsers.

I still support the mailto: extensions and would be willing to
discuss these as a separate thread.

But the access issue for the working medium of the Web Access
Initiative is to make the working conversations of the Initiative
as accessible as possible for those who by dint of disability
move through Internet media a little slower than some of the rest
of us.

To underscore the difference between the performance issue and
the mailto: solution, may I am repeating here for the benefit
of the working group list an alternative implementation strategy.

Since I am only aware of what Lynx and Netscape do, the following
feature may be no more widespread than the new mailto: which is
already implemented to some degree in those browsers.  There is a
practice of putting the URL to the page where a mailto: was found
in a header at the head of the mail message generated.  Some of the
field names that have been used by Lynx in this regard include
 
	X-within-URL:
	X-URL:

Other X-header spellings likely exist in the usage of other
browsers.  I think that almost all browsers that implement this
feature generate headers whose field name can be matched with a
*URL: pattern.

Suppose there were a preprocessor for mail received to a posting
addres such as w3c-wai-wg@w3.org, which preprocessor would get to
handle arriving mailgrams before they went to SmartList and
Hypermail for distribution and filing.  If this preprocessor
examined these *URL: headers, detected those that refer to
"known" messages, i.e. messages resident in the archives of the
W3C, and inserted the Message-ID value of the original message in
a References: header in the mail distributed and archived, the
context for the arriving mailgram would be known not only to
those that take the extra trouble to examine all headers on their
mail, but also to the archiver -- a critical step if slow players
are to be made as integral to the process as we can.

This assumes:

	Hypermail checks References: headers and builds threads
	based on them.

	The list posting address allows non-subscribers to post,
	either with or without manual screening.

I want to have this alternative strategy on record so that I can
place a high priority on supporting slow participants in the WAI
process.  I want to separate that concern from my support for the
mailto: syntax per the current Internet Draft.  I also support
the mailto: syntax as currently drafted, but the reasons for
preferring that solution are not all for broadband access to the
WAI work process.

--
Al Gilman

Received on Wednesday, 7 May 1997 11:48:28 UTC