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