Atom Link Relation: DiscussXMPP Standards FoundationP.O. Box 1641DenverCO80201USAstpeter@jabber.orgxmpp:stpeter@jabber.org
Applications
AtomThis specification defines a link relation that enables an Atom document to point to a venue for multi-party discussion of the document or its primary topic.Atom is an XML-based document format that describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata. Such metadata can include links to other resources, which are primarily defined by Uniform Resource Indentifiers or Internationalized Resource Indentifiers . A link can be secondarily defined as partaking in a specific kind of relationship to the document. This specification defines a new link relation, "discuss", which can be used to point to Internet resources where a person can actively engage in a multi-party discussion or conversation about the document itself or the primary topic covered by the document.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .This specification allows the use of Internationalized Resource Identifiers . Every Uniform Resource Identifier is also an IRI, so a URI may be used wherever an IRI is named. When an IRI that is not also a URI is given for dereferencing, it MUST be mapped to a URI using the steps in Section 3.1 of . When an IRI is serving as an identifier, it MUST NOT be so mapped.An Atom link element with a rel attribute value of "discuss" is used to reference an Internet resource where multi-party discussion of the feed, entry, or source can occur. In the terminology of this specification, such a resource is called a "venue". Such venues might include, but are not limited to, the following:Electronic mail discussion listsNetwork news discussion boards (see )Internet Relay Chat channels (see )Web-based forums accessible via the Hypertext Transport Protocol (see )Multi-user chat rooms based on the Extensible Messaging and Presence Protocol (see and )Multi-user chat rooms based on the Message Session Relay Protocol (see )Voice or video conference rooms based on the Session Initiation Protocol (see )The use of the "discuss" relation enables a person who receives an Atom feed or entry to discover a venue where the person can engage in a conversation about the feed or entry with interested others. This use case is not currently addressed by any existing Atom link relation, which to date address use cases such as reading background material (the "related" relation) or following other people's comments (the "comments" relation) rather than actively engaging in a conversation or discussion about the feed or entry.It is expected that a link relation of type "discuss" would be presented to a human user in such a way that the user would understand that following the link would result in joining an active discussion venue rather than accessing a static resource.If the rel attribute has a value of "discuss" but the type attribute of the atom:link is omitted, no type value shall be assumed.Although Atom feed, entry, and source elements MAY each contain any number of atom:link elements using the "discuss" link relation, this specification assigns no significance to the presence or order of such links. Multiple discuss links appearing within an atom:entry may reference alternative representations of the same venue or may reference entirely distinct venues containing distinct conversations. Processors MUST NOT assume that multiple discuss links make reference to different representations of the same venue and MUST process each discuss link independently of any others.The following example shows an Atom entry that contains numerous links related to the ejabberd XMPP server project, including links to an XMPP chatroom, an email discussion list, a web forum, and two web pages with background information.Notice that the entry contains three links of type "relation" (which can be differentiated via the URI scheme, i.e., "xmpp" vs. "mailto" vs. http") and three links to HTTP resources (which can be differentiated via the relation type, i.e., "discuss" vs. "related").This document introduces few additional security considerations beyond those associated with the use and resolution of URIs/IRIs in general.However, depending on the technology used and the local service policy at a particular installation, a venue for multi-party discussion may expose personally-identifying information about the participants (e.g., IP addresses), may be public in the sense that anyone can join the venue, and may archive the conversations that occur in the venue either privately or publicly (e.g., on the World Wide Web). An Atom user agent or the appropriate helper application should warn a human user about the possibility of information exposure and public archiving.This specification defines one new Atom link relation type, which shall be registered in the IANA Registry of Atom Link Relations, as defined by .discuss(see )(see )(see )The Atom Syndication FormatInternationalized Resource Identifiers (IRIs)Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
Uniform Resource Identifier (URI): Generic SyntaxHypertext Transfer Protocol -- HTTP/1.1Department of Information and Computer ScienceUniversity of California, IrvineIrvineCA92697-3425+1(949)824-1715fielding@ics.uci.eduWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682jg@w3.orgCompaq Computer CorporationWestern Research Laboratory250 University AvenuePalo AltoCA94305mogul@wrl.dec.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682frystyk@w3.orgXerox CorporationMIT Laboratory for Computer Science, NE43-3563333 Coyote Hill RoadPalo AltoCA94034masinter@parc.xerox.comMicrosoft Corporation1 Microsoft WayRedmondWA98052paulle@microsoft.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682timbl@w3.org
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
Internet Relay Chat ProtocolTuirantie 17 as 9Oulu90500FIjto@tolsun.oulu.fi4 Pateman StreetWatsoniaVictoria3087AUavalon@coombs.anu.edu.auThe IRC protocol was developed over the last 4 years since it was first implemented as a means for users on a BBS to chat amongst themselves. Now it supports a world-wide network of servers and clients, and is stringing to cope with growth. Over the past 2 years, the average number of users connected to the main IRC network has grown by a factor of 10.The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server.The Message Session Relay Protocol (MSRP)This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS TRACK]Multi-User Chatstpeter@jabber.orgNetwork News Transfer ProtocolUniversity of California, San Diego (UCSD)University of California, Berkeley (UCB)SIP: Session Initiation ProtocolThis document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS TRACK] Extensible Messaging and Presence Protocol (XMPP): CoreJabber Software Foundation