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 00:22:52 -0700

text/plain (74 lines)

I detect some confustion that might stem from English not being
Jacob's native language.  No offense intended -- Just trying to help.

In the interests of proper Internationalization, I have some specific
suggestions for improvement of the grammar and semantics of the new
proposed text...

Look for ^ chars inserted below lines to be changed by replacement or
by new text insertion...

Great care must be taken to be sure I have not screwed things up!!!

From Jacob's message Sat, 23 Aug 1997 11:23:42 +0200:
}Here is a new draft text, based on your suggestions; exclamation
}marks in the border marks changes to the previous draft text:
}     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 has changed to allow characters not
                               ^^^ ^^^^^^^standard has been changed
}     allowed in mail headers. To include such a URL in a mail
   ^^^previously ^^^^MIME
}     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 may include cooperation with
}     the user and the software which produced the faulty URL. The
          ^^^^author            ^^^^^^^^^^^^^^used to produce
}     encoding method of RFC 1738 can make a correct URL faulty if
                                      ^^^^cause         ^to become
}     not done the right way. Changing the URL of documents already
}     available on the Internet or an Intranet may invalidate
}     existing links to this document. Changing the HTML body may
                        ^^^^^^^^^^^^^the changed document
}!    invalidate message integrity checks. For these reasons, this
}!    standards recommends method (b).
      ^^^^^^^^^standard only         ^unless the original author makes the changes.
}!    With method (b), the charset US-ASCII can be used, or, if the
                          ^parameter value "US-ASCII"
}     URL contains octets outside of the 7-bit range, "UKNOWN-8BIT"
}     [RFC 1428] or "UTF-8" may be appropriate. Note that for MHTML
}  ^^^can be used                                            ^the
      processing (matching of URLs in body text to URL in Content-
             ^^^^^ of      ^^^(delete)
}     Location headers) the choice of character encoding need not be
}     the "correct" choice, it need only be a choice which, after
                          ^^^^.  It
}     reversal of the encoding by the receiving mailer, returns the
}     same octet string as before the encoding.

I hope my "blue pencil" technique is not too ambiguous;-)...\Stef

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



CataList Email List Search Powered by the LISTSERV Email List Manager