|
Home >> FAQs/Tutorials >> RSS Tutorials >> Index
RSS FAQs - Atom Syndiation Format RFC4287 Reference Document
By: M. Nottingham, Ed. & R. Sayre, Ed.
Part:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
(Continued from previous part...)
7.1. Registry of Link Relations
This registry is maintained by IANA and initially contains five
values: "alternate", "related", "self", "enclosure", and "via". New
assignments are subject to IESG Approval, as outlined in [RFC2434].
Requests should be made by email to IANA, which will then forward the
request to the IESG, requesting approval. The request should use the
following template:
o Attribute Value: (A value for the "rel" attribute that conforms to
the syntax rule given in Section 4.2.7.2)
o Description:
o Expected display characteristics:
o Security considerations:
8. Security Considerations
8.1. HTML and XHTML Content
Text constructs and atom:content allow the delivery of HTML and
XHTML. Many elements in these languages are considered 'unsafe' in
that they open clients to one or more types of attack. Implementers
of software that processes Atom should carefully consider their
handling of every type of element when processing incoming (X)HTML in
Atom Documents. See the security sections of [RFC2854] and [HTML]
for guidance.
Atom Processors should pay particular attention to the security of
the IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, and
LINK elements, but other elements might also have negative security
properties.
(X)HTML can either directly contain or indirectly reference
executable content.
8.2. URIs
Atom Processors handle URIs. See Section 7 of [RFC3986].
8.3. IRIs
Atom Processors handle IRIs. See Section 8 of [RFC3987].
8.4. Spoofing
Atom Processors should be aware of the potential for spoofing attacks
where the attacker publishes an atom:entry with the atom:id value of
an entry from another feed, perhaps with a falsified atom:source
[Page 31]
element duplicating the atom:id of the other feed. For example, an
Atom Processor could suppress display of duplicate entries by
displaying only one entry from a set of entries with identical
atom:id values. In that situation, the Atom Processor might also
take steps to determine whether the entries originated from the same
publisher before considering them duplicates.
8.5. Encryption and Signing
Atom Documents can be encrypted and signed using
[W3C.REC-xmlenc-core-20021210] and [W3C.REC-xmldsig-core-20020212],
respectively, and are subject to the security considerations implied
by their use.
Digital signatures provide authentication, message integrity, and
non-repudiation with proof of origin. Encryption provides data
confidentiality.
9. References
9.1. Normative References
[HTML] Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01
Specification", W3C REC REC-html401-19991224,
December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>.
[MIMEREG] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media
Type", RFC 2854, June 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[Page 32]
(Continued on next part...)
Part:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|