Commit 229d491b authored by Per Cederqvist's avatar Per Cederqvist
Browse files

(Aux-Item Types): Remove inferior documentation of multipart handling

	by allowed-content-type; that is now obsoleted by the better
	documentation that Rasmus Sten provided.  Fix markup and
	language errors in the documentation by Rasmus.
(Multipart (multipart/mixed)): Fixed markup errors.  Clarify that
	text/x-kom-basic is preferred.
(MHTML (message/rfc822;x-lyskom-variant=rfc2557)): Fixed markup
	errors.  Clarify that it is automatic access to external
	resources that should be stopped.
parent a286065f
......@@ -10102,11 +10102,6 @@ priority numbers, it is a hint to the client about which content-type is
most desirable. Content-types that matches a lower priority number are
preferred.
Some content types (such as @samp{multipart/mixed} and
@samp{message/rfc822}) can contain other content types. In those
cases, all content types should be checked against the
@aux{allowed-content-type}.
As an example, consider a conference with the following four
@aux{allowed-content-type} aux-items:
......@@ -10130,10 +10125,10 @@ future, if experience shows that it is desirable to have the server
enforce the content type.
If a message is a composition of several different MIME types, for
example MIME multipart, each and every included content-types must be
checked against the recipients allowed-content-types
recursively. Example: a MIME multipart/mixed message with the following
structure:
example MIME multipart, each and every included content-type must be
checked against the @aux{allowed-content-type} aux-items recursively.
For instance, consider a MIME multipart/mixed message with the
following structure:
@example
(multipart/mixed)-+-(multipart/alternative)-+-(text/plain)
......@@ -10143,11 +10138,12 @@ structure:
@end example
For this message to be allowed, all five content types must be checked
against, and accepted by, the allowed-content-types aux-item(s). For a
conference to accept such a message, it is thus not enough to have an
allowed-content-type aux-item set to, for example, "1 multipart/*". It
must also include all possible included content-types. The following
allowed-content-types aux-items would allow this kind of messages:
against, and accepted by, the @aux{allowed-content-type} aux-item(s).
For a conference to accept such a message, it is thus not enough to
have an @aux{allowed-content-type} aux-item set to, for example,
@samp{1 multipart/*}. It must also include all included
content-types. The following @aux{allowed-content-type} aux-items
would allow this kind of message:
@example
1 text/*
......@@ -10346,7 +10342,7 @@ last line.
@menu
* Reformattable Text (text/x-kom-basic)::
* The User Area (x-kom/user-area)::
* Multipart (multipart/related)::
* Multipart (multipart/mixed)::
* MHTML (message/rfc822;x-lyskom-variant=rfc2557)::
@end menu
......@@ -10408,62 +10404,64 @@ article with the following structure:
It is recommended that the text part comes first. For the image
parts, it is recommended for the image parts to have the
"Content-Disposition" header set to "inline" if the user wants to
display all parts simultaneously. A client that encounters such a part
should attempt to display it inline with the rest of the message, if
feasible. If "Content-Disposition" is lacking or set to "attachment", a
client should show those parts as accessible by user interaction or
likewise.
@code{Content-Disposition} header set to @code{inline} if the user
wants to display all parts simultaneously. A client that encounters
such a part should attempt to display it inline with the rest of the
message, if feasible. If @code{Content-Disposition} is lacking or set
to @code{attachment}, a client should show those parts as accessible
by user interaction or likewise.
Note that the text content type is "text/x-kom-basic" and not
"text/plain".
Clients are encouraged to use @code{text/x-kom-basic} instead of
@code{text/plain}, as in the above example.
@node MHTML (message/rfc822;x-lyskom-variant=rfc2557)
@section MHTML articles
MHTML is a standard for encapsulating a HTML page in its entirety, with
images and other related resources, into a single MIME message. The MIME
type of this message is message/rfc822, plus the parameter
"x-lyskom-variant" set to "rfc2557". This allows a LysKOM client to
distinguish MHTML from conventional message/rfc822 articles, while
retaining the possibility to treat the text as a regular e-mail (for
example, pass it to an e-mail application for external interpretation).
MHTML is a standard for encapsulating a HTML page in its entirety,
with images and other related resources, into a single MIME message.
The MIME type of this message is @code{message/rfc822}, plus the
parameter @code{x-lyskom-variant} set to @code{rfc2557}. This allows
a LysKOM client to distinguish MHTML from conventional
@code{message/rfc822} articles, while retaining the possibility to
treat the text as a regular e-mail (for example, pass it to an e-mail
application for external interpretation).
MHTML is specified in RFC 2557. The following should be considered when
writing an MHTML-capable LysKOM-client:
MHTML is specified in RFC 2557. The following should be considered
when writing an MHTML-capable LysKOM client:
@itemize @bullet
@item Care should be taken to compare the allowed-content-type aux-item
@item Care should be taken to compare the @aux{allowed-content-type} aux-item
for all recipients of the article. Note that each part of the MIME
article must be accepted in order for the article to be allowed in its
entirety. For example, an MHTML article containing an HTML text and a
PNG image should check that the conference allows all four content
types embedded: message/rfc822, multipart/related, text/html and
image/png (see @aux{allowed-content-type} in @xref{Aux-Item Types}).
types embedded: @code{message/rfc822}, @code{multipart/related},
@code{text/html} and @code{image/png} (see @aux{allowed-content-type}
in @pxref{Aux-Item Types}).
@item While not technically wrong, clients are discouraged to create
MHTML article with only one part, for example a single image. Instead,
the article's content-type should be set to that one parts content-type,
and the article's contents the part's raw binary data.
@item While not technically wrong, clients are discouraged from creating
MHTML article with only one part, for example a single image.
Instead, the article's content-type should be set to that one parts
content-type, and the article's contents the part's raw binary data.
@item When displaying HTML, great care should be taken to minimize the
risk for the end-user, for example by disabling all scripting
possibilities and access to external resources. This may be done by
parsing the HTML and filtering out anything but a specified subset of
HTML tags and only "harmless" attributes of those tags.
possibilities and automatic access to external resources. This may be
done by parsing the HTML and filtering out anything but a specified
subset of HTML tags and only harmless attributes of those tags.
@item Clients should allow the creation of multipart/alternative parts
containing both text/plain and text/html when the user posts MHTML
texts. In accordance with the MIME and MHTML specification, the
"plainest" part should be first.
@item Clients should allow the creation of @code{multipart/alternative} parts
containing both @code{text/plain} and @code{text/html} when the user
posts MHTML texts. In accordance with the MIME and MHTML
specification, the "plainest" part should be first.
@item When creating the different parts in an MHTML article, make sure
to include a Content-Location header specifying the name as used in the
HTML, for all parts referenced to in the HTML part.
to include a @code{Content-Location} header specifying the name as
used in the HTML, for all parts referenced to in the HTML part.
@item The content-transfer-encoding should be set to binary; however,
clients should be prepared to decode other encodings as defined by the
MIME standard.
@item The @code{content-transfer-encoding} should be set to
@code{binary}; however, clients should be prepared to decode other
encodings as defined by the MIME standard.
@end itemize
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment