Commit b6160294 authored by Per Cederqvist's avatar Per Cederqvist

(Aux-Item Types): State that allowed-content-type should be applied

	recursively to all content types, in much more detail than in
	the change of 2004-07-18.
(Multipart (multipart/mixed)): New section.
(MHTML (message/rfc822;x-lyskom-variant=rfc2557)): New section.
parent 4d2c2bdc
......@@ -10129,6 +10129,32 @@ client (or to the author of a new text). This may change in the
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
(multipart/mixed)-+-(multipart/alternative)-+-(text/plain)
| |
| +-(text/html)
+-(image/gif)
@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:
@example
1 text/*
1 multipart/*
1 image/*
@end example
@item canonical-name [31] (server)
This should be set to the official domain name of the server,
......@@ -10320,6 +10346,8 @@ last line.
@menu
* Reformattable Text (text/x-kom-basic)::
* The User Area (x-kom/user-area)::
* Multipart (multipart/related)::
* MHTML (message/rfc822;x-lyskom-variant=rfc2557)::
@end menu
@node Reformattable Text (text/x-kom-basic)
......@@ -10362,6 +10390,83 @@ type as @samp{text/x-kom-basic} for improved interoperability.
This content type indicates that the article contains a user area.
@xref{The User Area}.
@node Multipart (multipart/mixed)
@section Multipart articles
Multipart can be used where the complexity of MHTML is not desired. In
the common case that the user wants to post a text containing an image
and a descriptive text (aside from the subject), there is usually no
need for advanced markup nor image references from within the text
body. In that situation, it is useful to instead create a multipart
article with the following structure:
@example
(multipart/mixed)-+-(text/x-kom-basic)
+-(image/jpeg)
+-(image/jpeg) ...
@end example
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.
Note that the text content type is "text/x-kom-basic" and not
"text/plain".
@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 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
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}).
@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 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.
@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 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.
@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.
@end itemize
@node The User Area
@chapter The User Area
......
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