idnits 2.17.1
draft-snell-atompub-bidi-05.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 16.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 261.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 272.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 279.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 285.
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 :
----------------------------------------------------------------------------
-- The draft header indicates that this document updates RFC4287, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
(Using the creation date from RFC4287, updated by this document, for
RFC5378 checks: 2004-07-09)
-- 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 (October 19, 2007) is 6028 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. 'ISO10646'
-- Possible downref: Non-RFC (?) normative reference: ref. 'UAX9'
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 10 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Snell
3 Internet-Draft October 19, 2007
4 Updates: 4287 (if approved)
5 Intended status: Standards Track
6 Expires: April 21, 2008
8 Atom Bidirectional Attribute
9 draft-snell-atompub-bidi-05.txt
11 Status of this Memo
13 By submitting this Internet-Draft, each author represents that any
14 applicable patent or other IPR claims of which he or she is aware
15 have been or will be disclosed, and any of which he or she becomes
16 aware will be disclosed, in accordance with Section 6 of BCP 79.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on April 21, 2008.
36 Copyright Notice
38 Copyright (C) The IETF Trust (2007).
40 Abstract
42 This document adds a new attribute to the Atom Syndication Format
43 used to indicate the base directionality of directionally-neutral
44 characters.
46 Table of Contents
48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
49 1.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . . 3
50 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 3
51 2. The "dir" Attribute . . . . . . . . . . . . . . . . . . . . . . 3
52 2.1. Direction Guessing . . . . . . . . . . . . . . . . . . . . 5
53 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
55 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
56 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6
57 5.2. Informative References . . . . . . . . . . . . . . . . . . 6
58 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6
59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
60 Intellectual Property and Copyright Statements . . . . . . . . . . 8
62 1. Introduction
64 This document updates the Atom Syndication Format [RFC4287] by adding
65 a new "dir" attribute used to define the base directionality of
66 directionally-neutral characters contained within an Atom document.
68 1.1. Namespace
70 The XML Namespaces URI [W3C.REC-xml-names-19990114] for the Atom
71 Syndication Format [RFC4287] is:
72 http://www.w3.org/2005/Atom
74 1.2. Notational Conventions
76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
78 document are to be interpreted as described in BCP 14, [RFC2119].
80 The Atom Syndication Format [RFC4287] is specified using terms from
81 the XML Infoset [W3C.REC-xml-infoset-20040204]. This specification
82 uses a shorthand form for two commons terms: The phrase "Information
83 Item" is omitted when naming Element and Attribute Information Items.
84 Therefore, when this specification uses the term "element," it is
85 referring to an Element Information Item in Infoset terms. Likewise,
86 when it uses the term "attribute," it is referring to an Attribute
87 Information Item.
89 Portions this specification are illustrated with fragments of a non-
90 normative RELAX NG Compact schema [RELAXNG]. However, the text of
91 this specification provides the sole definition of conformance.
93 2. The "dir" Attribute
95 The "dir" attribute specifies the base direction of directionally-
96 neutral text [ISO10646] in an Atom document. Possible values for the
97 attribute are "ltr" and "rtl" indicating "left-to-right" and "right-
98 to-left" respectively, or an empty string indicating that no base-
99 direction is specified. If a dir attribute is not provided, the
100 value MUST be assumed to be an empty string. The attribute can
101 appear on any element in an Atom document.
103 atomCommonAttributes =
104 attribute xml:base { atomUri }?,
105 attribute xml:lang { atomLanguageTag }?,
106 attribute dir { "ltr" | "rtl" | "" }?,
107 undefinedAttribute*
109 The direction specified by "dir" applies to elements and attributes
110 whose values are specified as being "Language-Sensitive" as defined
111 by Section 2 of [RFC4287]. The direction specified by the attribute
112 is inherited by descendant elements and attributes and may be
113 overridden.
115 Values other than "ltr", "rtl" and "" MUST be ignored and processed
116 as if the dir attribute was not present; Atom processors MUST NOT
117 stop processing or signal an error. The value of the attribute is
118 not case-sensitive. Leading or trailing whitespace MUST be ignored.
120 Example atom:feed with right-to-left directionality
122
123
124 ٹٺٻ
125 ...
126
128 If an Atom document contains bidirectional text, the Unicode
129 Bidirectional Algorithm [UAX9] SHOULD be used to render that text.
130 Because consumers of Atom documents vary broadly in the way they
131 display text, the "ltr" and "rtl" values do not necessarily open an
132 additional level of embedding or override with respect to the
133 bidirectional algorithm. Consuming applications that render
134 bidirectional text are responsible for determining the appropriate
135 level of embedding. If the dir attribute value is "rtl", Atom
136 processors that display affected text MAY choose to right-align that
137 text as per the rules described in Section 8 of
138 [W3C.REC-html401-19991224].
140 When Atom Text Constructs or the atom:content elements contain
141 bidirectional text and the type attribute value is either "html" or
142 "xhtml", the bidirectional markup mechanisms specific to each format
143 SHOULD be used. The value of the "dir" attribute does define the
144 base directionality of Language-Sensitive text within Text Constructs
145 and atom:content elements regardless of the value of the type
146 attribute.
148 Example atom:feed with bidirectional XHTML:
150
151
152 ...
153
154
157
158 ...
159
161 Unicode bidirectional control characters MAY also be used within
162 attributes and element values to indicate the directionality of text
163 or to modify the default operation of the Bidirectional Algorithm.
164 Implementers are reminded that unexpected results could occur when
165 using both the "dir" attribute and the Unicode control characters
166 within a single document.
168 2.1. Direction Guessing
170 In Atom documents that do not contain a "dir" attribute, it is
171 possible to apply heuristics to guess the base directionality of text
172 in the document. Such heuristics can take into consideration the in-
173 scope language context established by the use of the xml:lang
174 attribute or an analysis of the directional properties of the Unicode
175 characters used within the text. Such guessing algorithms can
176 produce reasonably acceptable results in many cases but cannot be
177 guaranteed to produce correct results in every case. For this
178 reason, explicit determination of text direction using the "dir"
179 attribute is preferred over any guessing algorithm.
181 For compatibility with existing Atom documents that rely on direction
182 guessing, user agents MAY perform direction guessing in documents
183 that do not contain a "dir" attribute but they SHOULD NOT do so when
184 an in-scope "dir" attribute is provided.
186 3. Security Considerations
188 The security considerations discussed in [RFC4287] Section 8 apply.
190 4. IANA Considerations
192 No IANA actions are required by this document.
194 5. References
195 5.1. Normative References
197 [ISO10646]
198 International Organization for Standardization, "ISO/IEC
199 10646:2003: Information Technology - Universal Multiple-
200 Octet Coded Character Set (UCS)", December 2003.
202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
203 Requirement Levels", BCP 14, RFC 2119, March 1997.
205 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
206 Syndication Format", RFC 4287, December 2005.
208 [UAX9] Davis, M., "Unicode Standard Annex #9: The Bidirectional
209 Algorithm", September 2006.
211 [W3C.REC-xml-infoset-20040204]
212 Tobin, R. and J. Cowan, "XML Information Set (Second
213 Edition)", World Wide Web Consortium Recommendation REC-
214 xml-infoset-20040204, February 2004,
215 .
217 [W3C.REC-xml-names-19990114]
218 Hollander, D., Layman, A., and T. Bray, "Namespaces in
219 XML", World Wide Web Consortium FirstEdition REC-xml-
220 names-19990114, January 1999,
221 .
223 5.2. Informative References
225 [RELAXNG] Clark, J., "RELAX NG Compact Syntax", December 2001, .
229 [W3C.REC-html401-19991224]
230 Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01
231 Specification", World Wide Web Consortium
232 Recommendation REC-html401-19991224, December 1999,
233 .
235 Appendix A. Acknowledgements
237 The author gratefully acknowledges the feedback from the Atom
238 Publishing Format and Protocol Working Group.
240 Author's Address
242 James M Snell
244 Email: jasnell@gmail.com
245 URI: http://www.snellspace.com
247 Full Copyright Statement
249 Copyright (C) The IETF Trust (2007).
251 This document is subject to the rights, licenses and restrictions
252 contained in BCP 78, and except as set forth therein, the authors
253 retain all their rights.
255 This document and the information contained herein are provided on an
256 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
257 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
258 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
259 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
260 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
261 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
263 Intellectual Property
265 The IETF takes no position regarding the validity or scope of any
266 Intellectual Property Rights or other rights that might be claimed to
267 pertain to the implementation or use of the technology described in
268 this document or the extent to which any license under such rights
269 might or might not be available; nor does it represent that it has
270 made any independent effort to identify any such rights. Information
271 on the procedures with respect to rights in RFC documents can be
272 found in BCP 78 and BCP 79.
274 Copies of IPR disclosures made to the IETF Secretariat and any
275 assurances of licenses to be made available, or the result of an
276 attempt made to obtain a general license or permission for the use of
277 such proprietary rights by implementers or users of this
278 specification can be obtained from the IETF on-line IPR repository at
279 http://www.ietf.org/ipr.
281 The IETF invites any interested party to bring to its attention any
282 copyrights, patents or patent applications, or other proprietary
283 rights that may cover technology that may be required to implement
284 this standard. Please address the information to the IETF at
285 ietf-ipr@ietf.org.
287 Acknowledgment
289 Funding for the RFC Editor function is provided by the IETF
290 Administrative Support Activity (IASA).