idnits 2.17.1
draft-snell-atompub-bidi-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 256.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 267.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 274.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 280.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (May 6, 2007) is 6199 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Possible downref: Non-RFC (?) normative reference: ref. 'UNI9'
-- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE'
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Snell
3 Internet-Draft May 6, 2007
4 Intended status: Standards Track
5 Expires: November 7, 2007
7 Atom Bidirectional Attribute
8 draft-snell-atompub-bidi-04.txt
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on November 7, 2007.
35 Copyright Notice
37 Copyright (C) The IETF Trust (2007).
39 Abstract
41 This document adds a new attribute to the Atom Syndication Format
42 used to indicate the base directionality of directionally-neutral
43 characters.
45 Table of Contents
47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
48 1.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . . 3
49 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 3
50 2. The "dir" Attribute . . . . . . . . . . . . . . . . . . . . . . 3
51 2.1. Direction Guessing . . . . . . . . . . . . . . . . . . . . 5
52 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
54 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
55 5.1. Normative References . . . . . . . . . . . . . . . . . . . 5
56 5.2. Informative References . . . . . . . . . . . . . . . . . . 6
57 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6
58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
59 Intellectual Property and Copyright Statements . . . . . . . . . . 7
61 1. Introduction
63 This document updates the Atom Syndication Format [RFC4287] by adding
64 a new 'dir' attribute used to define the base directionality of
65 directionally-neutral characters contained within an Atom document.
67 1.1. Namespace
69 The XML Namespaces URI [W3C.REC-xml-names-19990114] for the Atom
70 Syndication Format [RFC4287] is:
71 http://www.w3.org/2005/Atom
73 1.2. Notational Conventions
75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
77 document are to be interpreted as described in BCP 14, [RFC2119].
79 The Atom Syndication Format [RFC4287] is specified using terms from
80 the XML Infoset [W3C.REC-xml-infoset-20040204]. This specification
81 uses a shorthand form for two commons terms: The phrase "Information
82 Item" is omitted when naming Element and Attribute Information Items.
83 Therefore, when this specification uses the term "element," it is
84 referring to an Element Information Item in Infoset terms. Likewise,
85 when it uses the term "attribute," it is referring to an Attribute
86 Information Item.
88 Portions this specification are illustrated with fragments of a non-
89 normative RELAX NG Compact schema [RELAXNG]. However, the text of
90 this specification provides the sole definition of conformance.
92 2. The "dir" Attribute
94 The "dir" attribute specifies the base direction of directionally-
95 neutral text [UNICODE]. Possible values for the attribute are "ltr"
96 and "rtl" indicating "left-to-right" and "right-to-left"
97 respectively, or an empty string indicating that no base-direction is
98 specified. If a dir attribute is not provided, the value MUST be
99 assumed to be an empty string. The attribute can appear on any
100 element in an Atom document.
102 atomCommonAttributes =
103 attribute xml:base { atomUri }?,
104 attribute xml:lang { atomLanguageTag }?,
105 attribute dir { "ltr" | "rtl" | "" }?,
106 undefinedAttribute*
108 The direction specified by "dir" applies to elements and attributes
109 whose values are specified as being "Language-Sensitive" as defined
110 by Section 2 of [RFC4287]. The direction specified by the attribute
111 is inherited by descendent elements and attributes and may be
112 overridden.
114 Values other than "ltr", "rtl" and "" MUST be ignored and processed
115 as if the dir attribute was not present; Atom processors MUST NOT
116 stop processing or signal an error.
118 Example atom:feed with right-to-left directionality
120
121
122 ٹٺٻ
123 ...
124
126 If an Atom document contains any right-to-left characters, the
127 Unicode Bidirectional Algorithm [UNI9] SHOULD be used to render that
128 text. Because consumers of Atom documents vary broadly in the way
129 they display text, the "ltr" and "rtl" values do not necessarily open
130 an additional level of embedding with respect to the bidirectional
131 algorithm. Consuming applications that render bidirectional text are
132 responsible for determining the appropriate level of embedding. If
133 the dir attribute value is "rtl", Atom processors that display
134 affected text MAY choose to right-align that text as per the rules
135 described in Section 8 of [W3C.REC-html401-19991224].
137 When Atom Text Constructs or the atom:content elements contain
138 bidirectional text and the type attribute value is either "html" or
139 "xhtml", the bidirectional markup mechanisms specific to each format
140 SHOULD be used. The value of the "dir" attribute does define the
141 base directionality of Language-Sensitive text within Text Constructs
142 and atom:content elements regardless of the value of the type
143 attribute.
145 Example atom:feed with bidirectional XHTML:
147
148
149
150
153
154 ...
155
157 Unicode bidirectional control characters MAY also be used within
158 attributes and element values to indicate the directionality of text
159 or to modify the default operation of the Bidirectional Algorithm.
160 Implementers are reminded that unexpected results could occur when
161 using both the "dir" attribute and the Unicode control characters
162 within a single document.
164 2.1. Direction Guessing
166 In Atom documents that do not contain a "dir" attribute, it is
167 possible to apply heuristics to guess the base directionality of text
168 in the document. Such heuristics can take into consideration the in-
169 scope language context established by the use of the xml:lang
170 attribute or an analysis of the directional properties of the Unicode
171 characters used within the text. Such guessing algorithms can
172 produce reasonably acceptable results in many cases but cannot be
173 guaranteed to produce correct results in every case. For this
174 reason, explicit determination of text direction using the "dir"
175 attribute is preferred over any guessing algorithm.
177 For compatibility with existing Atom documents that rely on direction
178 guessing, user agents MAY perform direction guessing in documents
179 that do not contain a "dir" attribute but they SHOULD NOT do so when
180 a "dir" attribute is provided.
182 3. Security Considerations
184 The security considerations discussed in [RFC4287] Section 8 apply.
186 4. IANA Considerations
188 No IANA actions are required by this document.
190 5. References
192 5.1. Normative References
194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
195 Requirement Levels", BCP 14, RFC 2119, March 1997.
197 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
198 Syndication Format", RFC 4287, December 2005.
200 [UNI9] Davis, M., "The Bidirectional Algorithm", March 2004.
202 [UNICODE] International Organization for Standardization, "ISO/IEC
203 10646:2003: Information Technology - Universal Multiple-
204 Octet Coded Character Set (UCS)", December 2003.
206 [W3C.REC-xml-infoset-20040204]
207 Cowan, J. and R. Tobin, "XML Information Set (Second
208 Edition)", World Wide Web Consortium Recommendation REC-
209 xml-infoset-20040204, February 2004,
210 .
212 [W3C.REC-xml-names-19990114]
213 Layman, A., Bray, T., and D. Hollander, "Namespaces in
214 XML", World Wide Web Consortium FirstEdition REC-xml-
215 names-19990114, January 1999,
216 .
218 5.2. Informative References
220 [RELAXNG] Clark, J., "RELAX NG Compact Syntax", December 2001, .
224 [W3C.REC-html401-19991224]
225 Jacobs, I., Hors, A., and D. Raggett, "HTML 4.01
226 Specification", World Wide Web Consortium
227 Recommendation REC-html401-19991224, December 1999,
228 .
230 Appendix A. Acknowledgements
232 The author gratefully acknowledges the feedback from the Atom
233 Publishing Format and Protocol Working Group.
235 Author's Address
237 James M Snell
239 Email: jasnell@gmail.com
240 URI: http://www.snellspace.com
242 Full Copyright Statement
244 Copyright (C) The IETF Trust (2007).
246 This document is subject to the rights, licenses and restrictions
247 contained in BCP 78, and except as set forth therein, the authors
248 retain all their rights.
250 This document and the information contained herein are provided on an
251 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
252 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
253 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
254 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
255 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
256 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
258 Intellectual Property
260 The IETF takes no position regarding the validity or scope of any
261 Intellectual Property Rights or other rights that might be claimed to
262 pertain to the implementation or use of the technology described in
263 this document or the extent to which any license under such rights
264 might or might not be available; nor does it represent that it has
265 made any independent effort to identify any such rights. Information
266 on the procedures with respect to rights in RFC documents can be
267 found in BCP 78 and BCP 79.
269 Copies of IPR disclosures made to the IETF Secretariat and any
270 assurances of licenses to be made available, or the result of an
271 attempt made to obtain a general license or permission for the use of
272 such proprietary rights by implementers or users of this
273 specification can be obtained from the IETF on-line IPR repository at
274 http://www.ietf.org/ipr.
276 The IETF invites any interested party to bring to its attention any
277 copyrights, patents or patent applications, or other proprietary
278 rights that may cover technology that may be required to implement
279 this standard. Please address the information to the IETF at
280 ietf-ipr@ietf.org.
282 Acknowledgment
284 Funding for the RFC Editor function is provided by the IETF
285 Administrative Support Activity (IASA).