Re: LYNX-DEV X-URL header field

[Uzi Paz]

Any comments about using "X-URL" equivalent for mailing the stripped text
version via the "print" command? I don't know of any apropriate header
field, but it seems that "X-URL:" is definitly not good. Is there a need
for a new field for that? Or perhaps content-location without MIME.

- Uzi

On Fri, 21 Nov 1997, Foteos Macrides wrote:

>       Lou Montulli first implemented mailto, in the original,
> HYPERREZ Lynx, for use with the 'c'omment command.  HYPERREZ
> made much heavier use of LINK with REL/REV attributes than has
> been the case with WWW HTML.  A <LINK REV="made" HREF="mailto:To_value";>
> was used to indicate the author(s) or maintainer(s) of the document,
> and the scheme token was intended to communicate it's semantics:
> "What follows the To: in mailTo: is any value that would be acceptible
> in an email To: header -- including a comma-seperated list -- as
> specified in RFC 822."  The X-URL: header was used to indicate the
> URL of the document which contained the LINK with REV="made", preceded
> with "X-" because their is no "URL" email header.  There was no
> Content-Location header in those days, and I don't think it applies
> to Lynx's handling of 'c'omment.  The rendered document is included
> in the message with "angle bracket quoting", but that and the
> comment added by the user do not correspond to what would be received
> if the recipient of the message retrieved what is pointed to by the
> X-URL: header value (i.e., it's a reference, not, actually, the message
> content's location).
> 
>       Lynx also mails documents via its 'p'rint and 'd'ownload
> options menus.  These two commands were, and still are, misnomers.
> The so-call 'p'rint command invokes a menu of things the user can
> do with the *rendered* document that was being displayed when the
> command was issued.  The 'd'ownload command invokes a menu of things
> the user can do with the source (new and unrendered retrieval of that
> document).  BOTH menus can contain save-to-disk, mailing, printing,
> and downloading (e.g., Kermit) options.  When mailing via the
> 'd'ownload menu, a Content-Location: header would be valid to include
> (I think :).  In that case, Lynx presently includes a Content-Base:
> together with the Content-Type: header if the latter is text/html,
> so that partial and relative references in the source will be
> resolved properly if the recipient renders it.  It also still uses
> the Netscape hack of adding a BASE element at the top of the source
> (i.e., "corrupts" it :), for the benefit of recipients which do
> yet handle Content-Base: headers as intended.
> 
>       When a Lynx user toggles the display to source ('\') and
> then invokes the 'p'rint menu, selection of the mailing option
> will yield the same behavior with respect to headers (and the
> BASE element hack) described above for mailing via the 'd'ownload
> menu, but what gets mailed is not in fact the "source".  It is
> a rendering of the document as if it were text/html bounded in
> XMP.  I think a Content-Location header may be appropriate in
> this special case, but I'm not certain.  I don't think there's
> any uncertainty about the appropriateness of the Content-Base:
> header, because it still indicates how to resolve any partial
> or relative references.
> 
>       I've been following the discussions of the MHTML-WG,
> but still don't feel confident about the intended meanings
> and ramifications of the new headers.
>  
>                               Fote