Profile Support for the Atom Syndication FormatEMC6801 Koll Center ParkwayPleasanton, CA 94566U.S.A.+1-925-6006244erik.wilde@emc.comhttp://dret.net/netdret/The Atom syndication format is a generic XML format for representing collections. Profiles are one way how Atom feeds can indicate that they support specific extensions. To make this support visible on the media type level, this specification re-registers the Atom media type, and adds a "profile" media type parameter. This allows profiles to become visible at the media type level, so that servers as well as clients can indicate support for specific Atom profiles in conversations, for example when communicating via HTTP.This draft should be discussed on the atom-syntax mailing list.Online access to all versions and files is available on github.The Atom Syndication Format "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. For example, each entry has a title." Profiles "can be described as additional semantics that can be used to process a resource representation, such as constraints, conventions, extensions, or any other aspects that do not alter the basic media type semantics. A profile MUST NOT change the semantics of the resource representation when processed without profile knowledge, so that clients both with and without knowledge of a profiled resource can safely use the same representation." Profiles are identified by URI, and can be added to a representation by adding a link with the registered "profile" link relation type, linking to the profile URI. While this is sufficient to represent the fact that a certain representation is using a profile, it does not make that fact visible outside of this representation. Ideally, peers communicating their media type should be able to indicate the support of certain profiles through the media type itself, without changing the base media type.Because Atom supports generic links through its <link/> element, "profile" links can be easily added to a feed, indicating that this feed does adhere to a certain profile. However, on the media type level, this feed would still be labeled as application/atom+xml, making the profile invisible on that level and thus not allowing it to be used in interactions such as content negotiation in the Hypertext Transfer Protocol (HTTP). .This specification adds a "profile" parameter to the application/atom+xml media type, thereby making it possible for profiles to be exposed at the media type level. Apart from adding that one media type parameter, this specification does not change anything about the Atom format itself.Adding a "profile" parameter to the Atom media type adds visibility of profiles at the media type level. For example, when linking to feeds of media-oriented services, it would be possible to expose two feeds, one using MediaRSS, and the other using Podcasts. Both formats roughly cover the same functionality as media-oriented feed-based extensions, but by having the ability to expose their capabilities at the media type level, HTTP mechanisms and conversations can be used to distinguish between these formats.In some cases it may be possible to support more than one profile, and then it is up for the service to decide whether these should be exposed in one representation (which can be exposed by linking to multiple profiles from the resource representation and/or in the media type parameter), or whether there should be two representations, one for each profile. This decision will probably depend on implementation complexity, the trade-off between navigation complexity (two representations with one profile each) and processing complexity, and also the size of the profile data, because in particular in the case of overlapping profiles, there might be many redundacies.Thus, which way to go for multiple profiles is not a question that as one correct answer; it depends on the profiles, and on the services that are built around them.The profile parameter for the application/atom+xml media type allows one or more profile URIs to be specified. These profile URIs have the identifier semantics defined in , and when appearing as media type parameter, they have the same semantics as if they had been associated with the resource URI through other means, such as using one or more <link profile="" href=""/> element as a child of the <feed> element.Media type parameters must be quoted unless they are tokens. For the "profile" media type parameter defined here, this means that is must be quoted, and contains a non-empty list of space-separated URI-encoded URIs.When processing "mprofile" media type parameters, it is therefore important to apply URI-decoding before processing the URI (such as comparing it to known profiles). This is particularly important since profile URIs in Atom content (in <link profile="" href=""/> links) will not be URI-encoded, and thus properly encoding and decoding URIs in these two location is essential to implement correct processing.The Internet media type for an Atom document is application/atom+xml.This specification requests the registration of an XML-based media type for the eXtensible Access Control Markup Language (XACML).applicationatom+xmlnonecharset: This parameter has semantics identical to the charset parameter of the "application/xml" media type as specified in .profile: This parameter indicates that one or more profiles are used in the feed, according to the definition of profiles in . The parameter syntax is specified in of RFC XXXXIdentical to those of "application/xml" as described in , Section 3.2.As defined in . In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in , Section 10.There are no known interoperability issues.Many. Atom has become a common foundation for many syndication-oriented scenarios, and also has become a commonly used representation for collection contents.As specified for "application/xml" in , Section 3.2..atomAs specified for "application/xml" in , Section 5.As specified in , Section 6.TEXTMark Nottingham <mnot@mnot.net> and Erik Wilde <erik.wilde@emc.com>CommonIESGXML Media TypesThis document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet Mail Extensions) entities. [STANDARDS-TRACK]The Atom Syndication Formatmnot@pobox.comhttp://www.mnot.net/rfsayre@boswijck.comhttp://boswijck.comThis document specifies Atom, an XML-based Web content and metadata syndication format.The 'profile' Link Relation TypeThis specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms.Hypertext 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.orgThe 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.Media Type Specifications and Registration ProceduresThis document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.