usefor-article-04 April 2001
[< Prev]
[TOC] [ Next >]
9.3. Liability
There is a presumption that a poster who sends an article to Usenet
intends it to be stored on a multitude of serving agents, and has
therefore given permission for it to be copied to that extent.
Nevertheless, Usenet is not exempt from the Copyright laws, and it
should not be assumed that permission has been given for the article
to be copied outside of Usenet, not for its permanent archiving
contrary to any Archive header that may be present.
Posters also need to be aware that they are responsible if they
breach Copyright, Libel, Harrassment or other restrictions relating
to material that they post, and that they may possibly find
themselves liable for such breaches in jurisdictions far from their
own. Serving agents may also be liable in some jurisdictions,
especially if the breach has been explicitly drawn to their
attention.
Users who are concerned about such matters should seek advice from
competent legal authorities.
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../s-o-1036/Liability.out June 1994
+++ ../usefor-article-04/Liability.out April 2001
@@ -1,510 +1,20 @@
-11.4. Liability
+9.3. Liability
-News shares the legal uncertainty surrounding other forms of
-electronic communication: what rules apply to this new
-medium of information exchange? News is a particularly
-problematic case because it is a broadcast medium rather
-than a point-to-point one like mail, and analogies to older
-forms of communication are particularly weak.
+ There is a presumption that a poster who sends an article to Usenet
+ intends it to be stored on a multitude of serving agents, and has
+ therefore given permission for it to be copied to that extent.
+ Nevertheless, Usenet is not exempt from the Copyright laws, and it
+ should not be assumed that permission has been given for the article
+ to be copied outside of Usenet, not for its permanent archiving
+ contrary to any Archive header that may be present.
+ Posters also need to be aware that they are responsible if they
+ breach Copyright, Libel, Harrassment or other restrictions relating
+ to material that they post, and that they may possibly find
+ themselves liable for such breaches in jurisdictions far from their
+ own. Serving agents may also be liable in some jurisdictions,
+ especially if the breach has been explicitly drawn to their
+ attention.
-Are news-carrying hosts common carriers, like the phone com-
-panies, providing communications paths without having either
-authority over or responsibility for content? Or are they
-publishers, responsible for the content regardless of
-whether they are aware of it or not? Or something in
-between? Such questions are particularly significant when
-the content is technically criminal, e.g. some types of sex-
-ually-oriented material in some jurisdictions, in which case
-ignorance of its presence may not be an adequate defence.
-
-Even in milder situations such as libel or copyright viola-
-tion, the responsibilities of the poster, his host, and
-other hosts carrying the traffic are unclear. Note, in par-
-ticular, the problems arising when the article is a forgery,
-or when the alleged author claims it is a forgery but cannot
-prove this.
-
-
-A. Archeological Notes
-
-
-A.1. A-News Article Format
-
-The obsolete "A News" article format consisted of exactly
-five lines of header information, followed by the body. For
-example:
-
- Aeagle.642
- news.misc
- cbosgd!mhuxj!mhuxt!eagle!jerry
- Fri Nov 19 16:14:55 1982
- Usenet Etiquette - Please Read
- body
- body
- body
-
-The first line consisted of an "A" followed by an article ID
-(analogous to a message ID and used for similar purposes).
-The second line was the list of newsgroups. The third line
-was the path. The fourth was the date, in the format above
-
-INTERNET DRAFT to be NEWS sec. A.1
-
-
-(all fields fixed width), resembling an Internet date but
-not quite the same. The fifth was the subject.
-
-This format is documented for archeological purposes only.
-Do not generate articles in this format.
-
-
-A.2. Early B-News Article Format
-
-The obsolete pseudo-Internet article format, used briefly
-during the transition between the A News format and the mod-
-ern format, followed the general outline of a MAIL message
-but with some non-standard headers. For example:
-
- From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
- Newsgroups: news.misc
- Title: Usenet Etiquette -- Please Read
- Article-I.D.: eagle.642
- Posted: Fri Nov 19 16:14:55 1982
- Received: Fri Nov 19 16:59:30 1982
- Expires: Mon Jan 1 00:00:00 1990
-
- body
- body
- body
-
-The From header contained the information now found in the
-Path header, plus possibly the full name now typically found
-in the From header. The Title header contained what is now
-the Subject content. The Posted header contained what is
-now the Date content. The Article-I.D. header contained an
-article ID, analogous to a message ID and used for similar
-purposes. The Newsgroups and Expires headers were approxi-
-mately as now. The Received header contained the date when
-the latest relayer to process the article first saw it. All
-dates were in the above format, with all fields fixed width,
-resembling an Internet date but not quite the same.
-
-This format is documented for archeological purposes only.
-Do not generate articles in this format.
-
-
-A.3. Obsolete Headers
-
-Early versions of news software following the modern format
-sometimes generated headers like the following:
-
- Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
- Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
- Date-Received: Friday, 19-Nov-82 16:59:30 EST
-
-Relay-Version contained version information about the
-relayer that last processed the article. Posting-Version
-contained version information about the posting agent that
-
-INTERNET DRAFT to be NEWS sec. A.3
-
-
-posted the article. Date-Received contained the date when
-the last relayer to process the article first saw it (in a
-slightly nonstandard format).
-
-These headers are documented for archeological purposes
-only. Do not generate articles using them.
-
-
-A.4. Obsolete Control Messages
-
-There once was a senduuname control message, resembling
-sendsys but requesting transmission of the list of hosts
-that the receiving host had UUCP connections to. This
-rapidly ceased to be of much use, and many organizations
-consider information about their internal connectivity to be
-confidential.
-
-Historically, a checkgroups body consisting of one or two
-lines, the first of the form "-n newsgroup", caused check-
-groups to apply to only that single newsgroup. This form is
-documented for archeological purposes only; do not use it.
-
-Historically, an article posted to a newsgroup whose name
-had exactly three components of which the third was "ctl"
-signified that article was to be taken as a control message.
-The Subject header specified the actions, in the same way
-the Control header does now. This form is documented for
-archeological purposes only; do not use it; do not implement
-it.
-
-
-B. A Quick Tour Of MIME
-
-(The editor wishes to thank Luc Rooijakkers; most of this
-appendix is a lightly-edited version of a summary he kindly
-supplied.)
-
-MIME (Multipurpose Internet Mail Extensions) is an upward-
-compatible set of extensions to RFC 822, currently docu-
-mented in RFCs 1341 and 1342. This appendix summarizes
-these documents. See the MIME RFCs for more information;
-they are very readable.
-
- UNRESOLVED ISSUE: These RFC numbers (here and
- elsewhere in this Draft) need updating when the
- new MIME RFCs come out.
-
-MIME defines the following new headers:
-
-INTERNET DRAFT to be NEWS sec. B
-
-
- MIME-Version
- Content-Type
- Content-Transfer-Encoding
- Content-ID
- Content-Description
-
-
-The MIME-Version header is mandatory for all messages con-
-forming to the MIME specification and carries the version
-number of the MIME specification. Example:
-
- MIME-Version: 1.0
-
-
-The Content-Type header indicates the content type of the
-message. Content types are split into a top-level type and
-a subtype, separated by a slash. Auxiliary information can
-also be supplied, using an attribute-value notation. Exam-
-ple:
-
- Content-Type: text/plain; charset=us-ascii
-
-(In the absence of a Content-Type header this is in fact the
-default content type.)
-
-Important type/subtype combinations are
-
-text/plain Plain text, possibly in a non-
- ASCII character set.
-
-text/enriched A very simple wordprocessor-like
- language supporting character
- attributes (e.g., underlining),
- justification control, and multi-
- ple character sets. (This pro-
- posal has gone through several
- iterations and has recently split
- off from the main MIME RFCs into a
- separate document.)
-
-message/rfc822 A mail message conforming to a
- slightly-relaxed version of RFC
- 822.
-
-message/partial Part of a message (supporting the
- transparent splitting and joining
- of messages when they are too
- large to be handled by some trans-
- port agent).
-
-message/external-body A message whose body is external.
- Possible access methods include
- via mail, FTP, local file, etc.
-
-INTERNET DRAFT to be NEWS sec. B
-
-
-multipart/mixed A message whose body consists of
- multiple parts, possibly of dif-
- ferent types, intended to be
- viewed in serial order. Each part
- looks like an RFC 822 message,
- consisting of headers and a body.
- Most of the RFC 822 headers have
- no defined semantics for body
- parts.
-
-multipart/parallel Likewise, except that the parts
- are intended to be viewed in par-
- allel (on user agents that support
- it).
-
-multipart/alternative Likewise, except that the parts
- are intended to be semantically
- equivalent such that the part that
- best matches the capabilities of
- the environment should be dis-
- played. For example, a message
- may include plain-text, enriched-
- text, and postscript versions of
- some document.
-
-multipart/digest A variant of multipart/mixed espe-
- cially intended for message
- digests (the default type of the
- parts is message/rfc822 instead of
- text/plain, saving on the number
- of headers for the parts).
-
-application/postscript A PostScript document.
- (PostScript is a trademark of
- Adobe.)
-
-Other top-level types exist for still images, audio, and
-video samples.
-
-Some of the above types require the ability to transport
-binary data. Since the existing message systems usually do
-not support this, MIME provides a Content-Transfer-Encoding
-header to indicate the kind of encoding used. The possible
-encodings are:
-
-7bit No encoding; the data consists of short
- (less than 1000 characters) lines of
- 7-bit ASCII data, delimited by EOL
- sequences. This is the default encod-
- ing.
-
-8bit Like 7bit, except that bytes with the
- high-order bit set may be present.
- Many transmission paths are incapable
-
-INTERNET DRAFT to be NEWS sec. B
-
-
- of carrying messages which use this
- encoding.
-
-binary No encoding; any sequence of bytes may
- be present. Many transmission paths
- are incapable of carrying messages
- which use this encoding.
-
-base64 The data is encoded by representing
- every group of 3 bytes as 4 characters
- from the alphabet "A-Za-z0-9+/", which
- was chosen for its high robustness
- through mail gateways (the alphabet
- used by uuencode does not survive
- ASCII-EBCDIC-ASCII translations). In
- the final group of 4 characters, "=" is
- used for those characters not repre-
- senting data bytes. Line length is
- limited and EOLs in the encoded form
- are ignored.
-
-quoted-printable Any byte can be represented by a three
- character "=XX" sequence where the X's
- are upper case hexadecimal digits.
- Bytes representing printable 7-bit US-
- ASCII characters except "=" may be rep-
- resented literally. Tabs and blanks
- may be represented literally if not at
- the end of a line. Line length is lim-
- ited, and an EOL preceded by "=" was
- inserted for this purpose and is not
- present in the original.
-
-The base64 and quoted-printable encodings are applied to
-data in Internet canonical form, which means that any EOL
-encoded as anything but EOL must be an Internet canonical
-EOL: CR followed by LF.
-
-The Content-Description header allows further description of
-a body part, analogous to the use of Subject for messages.
-
-Finally, the Content-ID header can be used to assign an
-identification to body parts, analogous to the assignment of
-identifications to messages by Message-ID.
-
-Note that most of these headers are structured header
-fields, as defined in RFC 822. Consequently, comments are
-allowed in their values. The following is a legal MIME
-header:
-
- Content-Type: (a comment) text (yeah) /
- plain (and now some params:) ; charset= (guess what)
- iso-8859-1 (we don't have iso-10646 yet, pity)
-
-INTERNET DRAFT to be NEWS sec. B
-
-
- NOTE: Although the MIME specification was devel-
- oped for mail, there is nothing precluding its use
- for news as well. While it might simplify imple-
- mentation to restrict the MIME headers somewhat,
- in the same way that other news headers (e.g.
- From) are restricted subsets of the RFC-822 origi-
- nals, this would add yet another divergence
- between two formats that ought to be as compatible
- as possible. In the case of the MIME headers,
- there is no body of existing code posing compati-
- bility concerns. A full-featured MIME reading
- agent needs a full RFC-822 parser anyway, to prop-
- erly handle body parts of types like mes-
- sage/rfc822, so there is little gain from
- restricting MIME headers. Adopting the MIME spec-
- ification unchanged seems best. However, article-
- level MIME headers must still comply with the
- overall news header syntax given in section 4, so
- that news software which is NOT interested in MIME
- need not contain a full RFC-822 parser.
-
-The second part of MIME, RFC 1342 (Representation of Non-
-ASCII Text in Internet Message Headers), addresses the prob-
-lem of non-ASCII characters in headers. An example of a
-header using the RFC 1342 mechanism is
-
- From: =?ISO-8859-1?Q?Andr=E9_?= Pirard <PIRARD@vm1.ulg.ac.be>
-
-Such encodings are allowed in selected headers, subject to
-the restrictions listed in RFC 1342.
-
-The MIME effort has also produced an RFC defining a Content-
-MD5 header [rrr 1544], containing an MD5-based "checksum" of
-the contents of an article or body part, giving high confi-
-dence of detecting accidental modifications to the contents.
-
-The "metamail" software package [rrr] helps provide MIME
-support with minimal changes to mailers, and may also be
-relevant to news reading agents.
-
-The PEM (Privacy Enhanced Mail) effort is pursuing analogous
-facilities to offer stronger guarantees against malicious
-modifications, unauthorized eavesdropping, and forgery.
-This work too may be applicable to news, once it is recon-
-ciled with MIME (by efforts now underway).
-
-
-C. Summary of Changes Since RFC 1036
-
-This Draft is much longer than RFC 1036, so there is obvi-
-ously much change in content. Much of this is just
-increased precision and rigor. Noteworthy changes and addi-
-tions include:
-
-INTERNET DRAFT to be NEWS sec. C
-
-
- + section 4.3's restrictions on article bodies
-
- + all references to MIME facilities
-
- + size limits on articles
-
- + precise specification of Date-content syntax
-
- + message IDs must never be re-used, ever
-
- + "!" is the only Path delimiter
-
- + multiple moderators in the Approved header
-
- + rules on References trimming, and the _-_ mechanism
-
- + generalization of the Xref rules
-
- + multiple message IDs in Cancel and Supersedes
-
- + Also-Control
-
- + See-Also
-
- + Article-Names
-
- + Article-Replacing
-
- + more precise rules for cancellation
-
- + cancellation authorization based on From, not Sender
-
- + "unmoderated" and descriptors in newgroup messages
-
- + restrictive rules on handling of sendsys and version
- messages
-
- + the whogets control message
-
- + precise specification of checkgroups messages
-
- + compression type preferably specified out-of-band
-
- + rules for encapsulating news in MIME mail
-
- + tighter specification of relayer functioning (section
- 9.1)
-
- + the "newsmaster" contact address
-
- + rules for gatewaying (section 10)
-
- + discussion of security issues (section 11)
-
-INTERNET DRAFT to be NEWS sec. C
-
-
-D. Summary of Completely New Features
-
-Most of this Draft merely documents existing practice, but
-there are a few attempts to extend it. These are:
-
-TBW
-
-
-E. Summary of Differences From RFC 822+1123
-
-The following are noteworthy differences between this
-Draft's articles and MAIL messages:
-
- + generally less-permissive header syntax
-
- + notably, limited From syntax
-
- + MAIL header comments allowed in only a few contexts
-
- + slightly more restricted message-ID syntax
-
- + several more mandatory headers
-
- + duplicate headers forbidden
-
- + References/See-Also versus In-Reply-To/References
- (section 6.5)
-
- + case sensitivity in some contexts
-
- + point-to-point headers, e.g. To and Cc, forbidden
- (section 6)
-
- + several new headers
-
-
-References
-
-[Sanderson] "Smileys", David Sanderson, O'Reilly & Associ-
-ates Ltd., 1993.
-
-TBW
-
-
-Security Considerations
-
-Section 11 discusses security considerations in detail.
-
-
-Author's Address
-
-INTERNET DRAFT to be NEWS sec. -
-
-
- Henry Spencer
- henry@zoo.toronto.edu
-
- SP Systems
- Box 280 Stn. A
- Toronto, Ont. M5W1B2 Canada
+ Users who are concerned about such matters should seek advice from
+ competent legal authorities.