LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives

MHTML Archives

MHTML Archives


Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font


Join or Leave MHTML
Reply | Post New Message
Search Archives

Subject: Re: More on wrongly(?) formatted urls
From: Einar Stefferud <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Sun, 24 Aug 1997 14:30:05 -0700

text/plain (72 lines)

From your message Sun, 24 Aug 1997 14:31:20 +0200:
}At 00.22 -0700 97-08-24, Einar Stefferud wrote:

}The only thing I am not sure I agree with in this text is the
}statement at the end of the fourth paragraph: "For these reasons,
}this standard only recommends method (b)".
}It seems rather funny to say that a standard only recommends
}keeping errors in using another standard, and does not recommend
}correcting those errors.

Hello Jacob -- I agree with your concerns, so let me try to fix
it;-)...  I have inserted some words to convey your observation that
authors/owners should certainly be expected to fix things that they
have created and which are broken.

Now, I have a new question -- Does this text belong in the standard or
in the Information RFC?  Does this go into the Standard as "How to be
liberal in handling what is received"?  It seems to be talking about
how to prepare HTML for sending.

I am only asking because I think we should all be very clear about
this sort of thing before we adopt it.


}     Handling of URLs containing inappropriate characters
}     Some URLs may contain characters that are inappropriate for an
}     RFC 822 header, either because the URL itself has an incorrect
}     syntax or the URL syntax standard has been changed to allow
}     characters not previously allowed in MIME headers. To include
}     such a URL in a mail header, an implementation can either (a)
}     arrange so that the URL becomes correctly formatted or (b)
}     encode the header using the encoding method described in RFC
}     2047.
}     Method (a) MUST be applied to the URL both in Content-
}     Location headers and in body text. It MUST NOT be reversed by
}     receiving mailers before matching hyperlinks to body parts.
}     Method (b) MUST not be applied to the URL in the HTML text and
}     MUST be reversed by receiving clients before comparing
}     hyperlinks in body text to URLs in Content-Location headers.
}     Method (a) is not always easy. It MUST include cooperation
}     with the author and the software used to produce the faulty
}     URL. The encoding method of RFC 1738 can cause a correct URL
}     to become faulty if not changed the right way. Changing the
}     URL of documents already available on the Internet or an
}     Intranet can invalidate existing links to the changed
}     document. Changing the HTML body can also invalidate message
}     integrity checks. For these reasons, this standard only
}     recommends method (b).
                           ^, unless the author or owner is involved
                              in the repair process.
}     With method (b), the charset parameter value US-ASCII can be
}     used, or, if the URL contains octets outside of the 7-bit
}     range, "UKNOWN-8BIT" [RFC 1428] or "UTF-8" may be appropriate.
}     Note that for the MHTML processing of (matching URLs in body
}     text to URL in) Content-Location headers the choice of
}     character encoding need not be the "correct" choice. It need
}     only be a choice which, after reversal of the encoding by the
}     receiving mailer, returns the same octet string as before the
}     encoding.

Back to: Top of Message | Previous Page | Main MHTML Page



CataList Email List Search Powered by the LISTSERV Email List Manager