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:Wed, 27 Aug 1997 10:29:31 -0700

text/plain (42 lines)

It seems to me that MIME is the defining standard for what is or is
not allowed or requires in MIME Content-* headers.

RFC822 is not as restrictive as is MIME, so MIME should be our

Is this not correct?  Best...\Stef

From your message Wed, 27 Aug 1997 14:49:20 +0200:
}At 16.36 +0200 97-08-26, Martin J. D=FCrst 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
}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:

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



CataList Email List Search Powered by the LISTSERV Email List Manager