LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives


MHTML Archives

MHTML Archives


View:

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

Options:

Join or Leave MHTML
Reply | Post New Message
Search Archives


Subject: Re: More on wrongly(?) formatted urls
From: Jacob Palme <[log in to unmask]>
Reply-To:IETF working group on HTML in e-mail <[log in to unmask]>
Date:Wed, 27 Aug 1997 14:49:20 +0200
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (32 lines)


At 16.36 +0200 97-08-26, Martin J. Dürst wrote:
> Well, I have no problem agreeing. But either way, we would not create our
> own definition. In one case, we would use the 822 definition, in the
> other case the 1738 definition. From an implementation viewpoint
> (I'm not an implementer, just guessing), I assume that basing it on
> 822 is easier, because the average MIME-aware mail software already
> has a function: Encode-this-header-if-necessary (where necessary
> is defined in 822 terms).

822 does not have very much of a definition of what characters are allowed
in headers. Each header has its own definition of how its value can look
like.

In our case, SPACE is a character which should be encoded. But there is
nothing in 822 which forbids SPACEs in headers. (They are forbidden
within certain field values of certain headers, but not generally
forbidden.) 822 also specifies two encoding methods for characters
otherwise not permitted (these encoding methods are called "quoting") and
if they are used, 822 allows almost any character almost anywhere. This is
a problem with 822, because many implementations will not work when for
example quoted SPACE characters are used. even though RFC 822 says that
they are allowed. I am not sure if the new drums document has resolved
this problem, or if it still allows SPACEs in places where they will
in reality often not work.

It is much easier to refer to RFC 1738 in specifying which characters must
be encoded, because RFC 1738 is much more precise and strict than RFC 822
in definying which characters must be encoded.

------------------------------------------------------------------------
Jacob Palme <[log in to unmask]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

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

Permalink



LISTSRV.NORDU.NET

CataList Email List Search Powered by the LISTSERV Email List Manager