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: Einar Stefferud <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Wed, 27 Aug 1997 10:29:31 -0700
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

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
reference.

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
}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