Atom syndication. format pdf

Its element children consist of metadata elements followed by zero or more atom:entry The "atom:entry" Element child elements. This specification assigns no significance to the order of atom:entry The "atom:entry" Element elements within the feed. The following child elements are defined by this specification note that the presence of some of these elements is required :. If multiple atom:entry The "atom:entry" Element elements with the same atom:id The "atom:id" Element value appear in an Atom Feed Document, they represent the same entry.

One typical behavior would be to display only the entry with the latest atom:updated The "atom:updated" Element timestamp. Experience teaches that feeds that contain textual content are in general more useful than those that do not. Some applications one example is full-text indexers require a minimum amount of text or X HTML to function reliably and predictably. Feed producers should be aware of these issues. It is advisable that each atom:entry The "atom:entry" Element element contain a non-empty atom:title The "atom:title" Element element, a non-empty atom:content The "atom:content" Element element when that element is present, and a non-empty atom:summary The "atom:summary" Element element when the entry contains no atom:content The "atom:content" Element element.

The " atom:entry The "atom:entry" Element " element represents an individual entry, acting as a container for metadata and data associated with the entry. This element can appear as a child of the atom:feed The "atom:feed" Element element, or it can appear as the document i.

This specification assigns no significance to the order of appearance of the child elements of atom:entry The "atom:entry" Element. The following child elements are defined by this specification note that it requires the presence of some of these elements :. The " atom:content The "atom:content" Element " element either contains or links to the content of the entry. The content of atom:content The "atom:content" Element is Language-Sensitive.

On the atom:content The "atom:content" Element element, the value of the "type" attribute MAY be one of "text", "html", or "xhtml". If neither the type attribute nor the src attribute is provided, Atom Processors MUST behave as though the type attribute were present with a value of "text". The value is advisory; that is to say, when the corresponding URI mapped from an IRI, if necessary is dereferenced, if the server providing that content also provides a media type, the server-provided media type is authoritative.

The " atom:author The "atom:author" Element " element is a Person construct that indicates the author of the entry or feed. If an atom:entry The "atom:entry" Element element does not contain atom:author The "atom:author" Element elements, then the atom:author The "atom:author" Element elements of the contained atom:source The "atom:source" Element element are considered to apply.

In an Atom Feed Document, the atom:author The "atom:author" Element elements of the containing atom:feed The "atom:feed" Element element are considered to apply to the entry if there are no atom:author The "atom:author" Element elements in the locations described above.

The " atom:category The "atom:category" Element " element conveys information about a category associated with an entry or feed. This specification assigns no meaning to the content if any of this element. The "term" attribute is a string that identifies the category to which the entry or feed belongs. Category elements MUST have a "term" attribute. The "scheme" attribute is an IRI that identifies a categorization scheme.

Category elements MAY have a "scheme" attribute. The "label" attribute provides a human-readable label for display in end-user applications. The content of the "label" attribute is Language-Sensitive. Category elements MAY have a "label" attribute. The " atom:contributor The "atom:contributor" Element " element is a Person construct that indicates a person or other entity who contributed to the entry or feed.

The " atom:generator The "atom:generator" Element " element's content identifies the agent used to generate a feed, for debugging and other purposes.

The content of this element, when present, MUST be a string that is a human-readable name for the generating agent. The atom:generator The "atom:generator" Element element MAY have a "version" attribute that indicates the version of the generating agent. The " atom:id The "atom:id" Element " element conveys a permanent, universally unique identifier for an entry or feed. Note that the definition of "IRI" excludes relative references.

Put another way, an atom:id The "atom:id" Element element pertains to all instantiations of a particular Atom entry or feed; revisions retain the same content in their atom:id The "atom:id" Element elements.

It is suggested that the atom:id The "atom:id" Element element be stored along with the associated resource. Instances of atom:id The "atom:id" Element elements can be compared to determine whether an entry or feed is the same as one seen before. Processors MUST compare atom:id The "atom:id" Element elements on a character-by-character basis in a case-sensitive fashion.

As a result, two IRIs that resolve to the same resource but are not character-for-character identical will be considered different for the purposes of identifier comparison. For example, these are four distinct identifiers, despite the fact that they differ only in case:. The " atom:link The "atom:link" Element " element defines a reference from an entry or feed to a Web resource. The "href" attribute contains the link's IRI.

If the "rel" attribute is not present, the link element MUST be interpreted as if the link relation type is "alternate". Note that use of a relative reference other than a simple name is not allowed.

The value of "rel" describes the meaning of the link, but does not impose any behavioral requirements on Atom Processors. On the link element, the "type" attribute's value is an advisory media type: it is a hint about the type of the representation that is expected to be returned when the value of the href attribute is dereferenced. Note that the type attribute does not override the actual media type returned with the representation.

The "hreflang" attribute's content describes the language of the resource pointed to by the href attribute. The "title" attribute conveys human-readable information about the link. The content of the "title" attribute is Language-Sensitive. Link elements MAY have a title attribute. The "length" attribute indicates an advisory length of the linked content in octets; it is a hint about the content length of the representation returned when the IRI in the href attribute is mapped to a URI and dereferenced.

Note that the length attribute does not override the actual content length of the representation as reported by the underlying protocol. Link elements MAY have a length attribute. The " atom:published The "atom:published" Element " element is a Date construct indicating an instant in time associated with an event early in the life cycle of the entry.

Typically, atom:published The "atom:published" Element will be associated with the initial creation or first availability of the resource. The " atom:rights The "atom:rights" Element " element is a Text construct that conveys information about rights held in and over an entry or feed.

If an atom:entry The "atom:entry" Element element does not contain an atom:rights The "atom:rights" Element element, then the atom:rights The "atom:rights" Element element of the containing atom:feed The "atom:feed" Element element, if present, is considered to apply to the entry. If an atom:entry The "atom:entry" Element is copied from one feed into another feed, then the source atom:feed The "atom:feed" Element 's metadata all child elements of atom:feed The "atom:feed" Element other than the atom:entry The "atom:entry" Element elements MAY be preserved within the copied entry by adding an atom:source The "atom:source" Element child element, if it is not already present in the entry, and including some or all of the source feed's Metadata elements as the atom:source The "atom:source" Element element's children.

Such metadata SHOULD be preserved if the source atom:feed The "atom:feed" Element contains any of the child elements atom:author The "atom:author" Element , atom:contributor The "atom:contributor" Element , atom:rights The "atom:rights" Element , or atom:category The "atom:category" Element and those child elements are not present in the source atom:entry The "atom:entry" Element.

The atom:source The "atom:source" Element element is designed to allow the aggregation of entries from different feeds while retaining information about an entry's source feed. For this reason, Atom Processors that are performing such aggregation SHOULD include at least the required feed-level Metadata elements atom:id The "atom:id" Element , atom:title The "atom:title" Element , and atom:updated The "atom:updated" Element in the atom:source The "atom:source" Element element.

The " atom:subtitle The "atom:subtitle" Element " element is a Text construct that conveys a human-readable description or subtitle for a feed. The " atom:summary The "atom:summary" Element " element is a Text construct that conveys a short summary, abstract, or excerpt of an entry.

It is not advisable for the atom:summary The "atom:summary" Element element to duplicate atom:title The "atom:title" Element or atom:content The "atom:content" Element because Atom Processors might assume there is a useful summary when there is none. The " atom:title The "atom:title" Element " element is a Text construct that conveys a human-readable title for an entry or feed. The " atom:updated The "atom:updated" Element " element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant.

Therefore, not all modifications necessarily result in a changed atom:updated The "atom:updated" Element value. For example, a merchant might digitally sign a message that contains a discount coupon for its products.

A bank that uses Atom to deliver customer statements is very likely to want to sign and encrypt those messages to protect their customers' financial information and to assure the customer of their authenticity. Intermediaries may want to encrypt aggregated feeds so that a passive observer cannot tell what topics the recipient is interested in. Of course, many other examples exist as well. The algorithm requirements in this section pertain to the Atom Processor.

They require that a recipient, at a minimum, be able to handle messages that use the specified cryptographic algorithms. These requirements do not limit the algorithms that the sender can choose. The root of an Atom Document i. Section 6. However, many implementers do not use it because signed XML documents enclosed in other XML documents have their signatures broken. Intermediaries such as aggregators may need to add an atom:source The "atom:source" Element element to an entry that does not contain its own atom:source The "atom:source" Element element.

If such an entry is signed, the addition will break the signature. Thus, a publisher of individually-signed entries should strongly consider adding an atom:source The "atom:source" Element element to those entries before signing them. Implementers should also be aware of the issues concerning the use of markup in the "xml:" namespace as it interacts with canonicalization. Awareness of new con- tent position councilors as guides to government for citizens.

Abil- ity to aggregate new content or headlines from across multiple office locations and agencies. Journalists and other locally focused web sites will be among the primary feed users. Governments need to accept that while they control the content of the feed, the actual display of the headlines and content will vary.

Popular RSS feeds can use signif- icant amounts of bandwidth. Automated syndication requires use of a content management system.

Most viable content management systems have integrated RSS functions, but the sophistication, ease of use, and documentation of these tools vary. RSS RSS is a family of web feed formats used to publish frequently updated works—such as blog entries, news headlines, audio, and video—in a stan- dardized format. An RSS document includes full or summarized text, plus metadata such as publishing dates and authorship. Web feeds benefit pub- lishers by letting them syndicate content automatically.

They benefit read- ers who want to subscribe to timely updates from favored web sites or to aggregate feeds from many sites into one place. RSS feeds can be read using software called a reader that can be web-based, desktop-based, a mobile device, or any computerized Internet-connected device.

A standardized XML file format allows the information to be published once and viewed by many different programs. Web feeds allow software pro- grams to check for updates published on a web site. The feed can then be downloaded by web sites that syndicate content from the feed, or by feed reader programs that allow Internet users to subscribe to feeds and view their content.

The Atom format was developed as an alternative to RSS. Atom also provides a standard- ized way to export an entire blog, or parts of it, for backup or for importing into other blogging systems. A program known as a feed reader or aggregator can check web pages on behalf of a user and display any updated articles that it finds. It is com- mon to find web feeds on major web sites, as well as on many smaller ones.

In particular, many blog and wiki sites offer their web feeds in the Atom format. Client-side readers and aggregators may be designed as standalone pro- grams or as extensions to existing programs such as web browsers.

Browsers are moving toward integrated feed reader functions. Such programs are available for various operating systems. Some aggregators syndicate web feeds into new feeds, e. There are several search engines which provide search functionality over content published via these web feeds.

REST refers to a collection of network architecture principles which outline how resources are defined and addressed. These two meanings can conflict as well as overlap.

Application state and functional- ity are abstracted into resources. Every resource is uniquely addressable using a universal syntax for use in hypermedia links, and all resources share a uni- form interface for the transfer of state between client and resource.

This transfer state consists of a constrained set of well-defined operations and a constrained set of content types, optionally supporting code on demand. State transfer uses a protocol which is client-server based, stateless and cache- able, and layered. Layered system constraints allow intermediaries—proxies, gateways, and firewalls—to be intro- duced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching.

REST enables intermediate processing by constrain- ing messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate 3. Roy T. Standards for Messaging semantics and exchange information, and responses explicitly indi- cate cacheability.

In order to manipulate these resources, components of the network user agents and origin servers communicate via a standardized interface e. For example, a resource which is a circle may accept and return a representation which specifies a center point and radius, for- matted in SVG Scalable Vector Graphics , but may also accept and return a representation which specifies any three distinct points along the curve as a comma-separated list.

Any number of connectors clients, servers, caches, tunnels, etc. Thus an application can interact with a resource by knowing two things: the identifier of the resource, and the action required—it does not need to know whether there are caches, proxies, gateways, firewalls, tunnels, or any- thing else between it and the server actually holding the information.

The application does, however, need to understand the format of the informa- tion representation returned, which is typically an HTML, XML, or JSON document of some kind, although it may be an image, plain text, or any other content. REST provides improved response time and reduced server load due to its support for the caching of representations.

REST improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session. REST requires less client-side software to be written than other approaches, because a single browser can access any application and any resource. It provides equivalent functionality when compared to alternative approaches to communication, and it does not require a separate resource discovery mechanism, because of the use of hyperlinks in representations.

REST 5. Such a web service can be thought of as a collection of resources comprising three aspects: 1. The URI for the web service 2.

The ID can be any unique identifier. SOAP can form the foundation layer of a web services proto- col stack, providing a basic messaging framework on which web services can be built. As a simple example of how SOAP procedures can be used, a SOAP message can be sent to a web service-enabled web site—for example, a house price database—with the parameters needed for a search.

The site returns an XML-formatted document with the resulting data prices, loca- tion, features, etc. Because the data is returned in a standardized machine- parseable format, it may be integrated directly into a third-party site. The SOAP architecture consists of several layers of specifications for message format, message exchange patterns MEPs , underlying transport protocol bindings, message processing models, and protocol extensibility.

SOAP makes use of an Internet appli- cation-layer protocol as a transport protocol. Critics have argued that this is an abuse of such protocols, as it is not their intended purpose and therefore not a role they fulfill well.

Proponents of SOAP have drawn analogies to successful uses of protocols at various levels for tunneling other protocols. XML was chosen as the standard message format because of its widespread use by major corporations and open source devel- opment efforts. Additionally, a wide variety of freely available tools signifi- cantly eases the transition to a SOAP-based implementation. SOAP is versatile enough to allow for the use of different transport protocols.

SOAP is platform-inde- pendent, language-independent, and it is simple and extensible. This may not be an issue when only small messages are sent. To improve performance for the special case of XML with embedded binary objects, Message Transmission Optimization Mechanism was introduced. Only one party the client can use the services of the other. Developers must use polling instead of notification in these com- mon cases. Most uses of HTTP as a transport protocol are made in ignorance of how the operation is accomplished.

As a result, there is no way to know whether the method used is appropriate to the operation. A client is the end user, the server is the web site. The client making a HTTP request via a web browser or other tool sends the request to the server.

The responding server is called the origin server. All of these protocols are discussed in detail in the following paragraphs. Its use for retrieving linked resources led to the establishment of the World Wide Web. A client is the end-user, the server is the web site. The client making a HTTP request—using a web browser, spider, or other end-user tool—is referred to as the user agent. The responding server—which stores or creates resources such as HTML files and images—is called the origin server.

In between the user agent and origin server may be several intermediaries, such as proxies, gateways, and tunnels. In fact, HTTP can be implemented on top of any other protocol; all it requires is reliable transport, so any protocol, on the Internet or any other network, that provides reliable transport can be used.

Typically, an HTTP client initiates a request. It establishes a TCP con- nection to a particular port on a host port 80 by default. An HTTP server listening on that port waits for the client to send a request message.

It is also used for sending short messages and managing a session of real- time messages between two or more participants. In computing, a softphone is a software program for making telephone calls over the Inter- net using a general-purpose computer; a hardphone is a conventional telephone set. The core protocol methods provide SIP extensions for subscriptions, notifications, and publications.

The methods used, subscribe and notify, are defined in RFC Subscribe allows a user to subscribe to an event on a server. Notify is the method used whenever the event arises and the server responds back to the subscriber.

Another standard, RFC , defines precisely how to use these methods to establish and maintain pres- ence. Presence documents contain information encoded using XML. These documents are transported in the bodies of SIP messages. A framework for authorization poli- cies controlling access to application-specific data is defined in RFC and RFC SIP defines two modes of instant messaging, the Page mode and the Session mode.

This mode establishes no sessions, while the Session mode based on the Message Session Relay Protocol RFC , RFC defines text-based protocol for exchanging arbitrarily sized con- tent of any time between users. Jabber provides a carrier-grade, best-in- class presence and messaging platform. Unlike other instant messaging protocols, XMPP is an open standard.

Like email, anyone who has a domain name and an Internet connection can run the Jabber server 7. Standards for Security and chat with others. XMPP-based software is deployed on thousands of servers across the Internet. Because the client uses HTTP, most firewalls allow users to fetch and post messages without hindrance. Some web sites allow users to sign in to Jabber via their browser.

Furthermore, there are open public servers, such as www. These standards also apply to cloud- related IT activities and include specific steps that should be taken to ensure a secure environment is maintained that provides privacy and security of confidential information in a cloud environment.

Security standards are based on a set of key principles intended to protect this type of trusted envi- ronment. Messaging standards, especially for security in the cloud, must also include nearly all the same considerations as any other IT security endeavor. The following protocols, while not exclusively specific to cloud security, merit coverage here. In the next few sections, we explain what they are and how they are used in the cloud environment.

This means having overlapping systems designed to pro- vide security even if one system fails. An example is a firewall working in conjunction with an intrusion-detection system IDS. Defense in depth provides security because there is no single point of failure and no single- entry vector at which an attack can occur. This type of layered security is precisely what we are see- ing develop in cloud computing.

Traditionally, security was implemented at the endpoints, where the user controlled access. An organization had no choice except to put firewalls, IDSs, and antivirus software inside its own network. Today, with the advent of managed security services offered by cloud providers, additional security can be provided inside the cloud.

It allows businesses to securely send assertions between partner organizations regard- ing the identity and entitlements of a principal. Both SAML 1. The term SAML Core refers to the general syntax and semantics of SAML assertions as well as the protocol used to request and transmit those assertions from one system entity to another. SAML pro- tocol refers to what is transmitted, not how it is transmitted.

SAML standardizes queries for, and responses that contain, user authentication, entitlements, and attribute information in an XML format. Standards for Security This format can then be used to request security information about a prin- cipal from a SAML authority.

A SAML authority, sometimes called the asserting party, is a platform or application that can relay security informa- tion. The relying party or assertion consumer or requesting party is a part- ner site that receives the security information. A subject is an entity in a particular domain. A per- son identified by an email address is a subject, as might be a printer.

SAML assertions are usually transferred from identity providers to ser- vice providers. Assertions contain statements that service providers use to make access control decisions. Three types of statements are provided by SAML: authentication statements, attribute statements, and authorization decision statements. Authentication statements assert to a service provider that the principal did indeed authenticate with an identity provider at a particular time using a particular method of authentication.

Entity Metadata from the original source feed of an entry. Entity Represents an individual entry Acts as a container for metadata and data associated with the entry.

AtomElement Base class for feed, entry and source elements. Person A Person construct that indicates the author of the entry or feed. AtomElement Information about a category associated with an entry or feed. Text Contains or links to the content of the entry. Person A Person construct representing a contributor Indicates a person or other entity who contributed to the entry or feed.

AtomElement Identifies the agent used to generate a feed The agent is used for debugging and other purposes. AtomElement An image that provides iconic visual identification for a feed. AtomElement A permanent, universally unique identifier for an entry or feed. AtomElement A reference from an entry or feed to a Web resource. Icon An image that provides visual identification for a feed. Date A Date construct indicating an instant in time associated with an event early in the life cycle of the entry.

Text A Text construct that conveys information about rights held in and over an entry or feed. Text A Text construct that conveys a human-readable description or subtitle for a feed. Text A Text construct that conveys a short summary, abstract, or excerpt of an entry. Text A Text construct that conveys a human-readable title for an entry or feed. Date A Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant.

AtomElement A human-readable name for a person. AtomElement An e-mail address associated with a person class pyslet. Enumeration text type enumeration: "text" "html" "xhtml".