idnits 2.17.1
draft-snell-atompub-bidi-06.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 265.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 276.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 283.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 289.
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 (April 11, 2008) is 5858 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
No issues found here.
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Snell
3 Internet-Draft April 11, 2008
4 Updates: 4287 (if approved)
5 Intended status: Experimental
6 Expires: October 13, 2008
8 Atom Bidirectional Attribute
9 draft-snell-atompub-bidi-06.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 October 13, 2008.
36 Copyright Notice
38 Copyright (C) The IETF Trust (2008).
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 Marking bidirectional text using the mechanism defined in this
69 specification is currently considered to be experimental.
70 Implementation and feedback are encouraged.
72 1.1. Namespace
74 The XML Namespaces URI [W3C.REC-xml-names-19990114] for the Atom
75 Syndication Format [RFC4287] is:
76 http://www.w3.org/2005/Atom
78 1.2. Notational Conventions
80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
82 document are to be interpreted as described in BCP 14, [RFC2119].
84 The Atom Syndication Format [RFC4287] is specified using terms from
85 the XML Infoset [W3C.REC-xml-infoset-20040204]. This specification
86 uses a shorthand form for two commons terms: The phrase "Information
87 Item" is omitted when naming Element and Attribute Information Items.
88 Therefore, when this specification uses the term "element," it is
89 referring to an Element Information Item in Infoset terms. Likewise,
90 when it uses the term "attribute," it is referring to an Attribute
91 Information Item.
93 Portions this specification are illustrated with fragments of a non-
94 normative RELAX NG Compact schema [RELAXNG]. However, the text of
95 this specification provides the sole definition of conformance.
97 2. The "dir" Attribute
99 The "dir" attribute specifies the base direction of directionally-
100 neutral text [ISO10646] in an Atom document. Possible values for the
101 attribute are "ltr" and "rtl" indicating "left-to-right" and "right-
102 to-left" respectively, or an empty string indicating that no base-
103 direction is specified. If a dir attribute is not provided, the
104 value MUST be assumed to be an empty string. The attribute can
105 appear on any element in an Atom document.
107 atomCommonAttributes =
108 attribute xml:base { atomUri }?,
109 attribute xml:lang { atomLanguageTag }?,
110 attribute dir { "ltr" | "rtl" | "" }?,
111 undefinedAttribute*
113 The direction specified by "dir" applies to elements and attributes
114 whose values are specified as being "Language-Sensitive" as defined
115 by Section 2 of [RFC4287]. The direction specified by the attribute
116 is inherited by descendant elements and attributes and may be
117 overridden.
119 Values other than "ltr", "rtl" and "" MUST be ignored and processed
120 as if the dir attribute was not present; Atom processors MUST NOT
121 stop processing or signal an error. The value of the attribute is
122 not case-sensitive.
124 Example atom:feed with right-to-left directionality
126
127
128 ٹٺٻ
129 ...
130
132 If an Atom document contains bidirectional text, the Unicode
133 Bidirectional Algorithm [UAX9] SHOULD be used to render that text.
134 Because consumers of Atom documents vary broadly in the way they
135 display text, the "ltr" and "rtl" values do not necessarily open an
136 additional level of embedding or override with respect to the
137 bidirectional algorithm. Consuming applications that render
138 bidirectional text are responsible for determining the appropriate
139 level of embedding. If the dir attribute value is "rtl", Atom
140 processors that display affected text MAY choose to right-align that
141 text as per the rules described in Section 8 of
142 [W3C.REC-html401-19991224].
144 When Atom Text Constructs or the atom:content elements contain
145 bidirectional text and the type attribute value is either "html" or
146 "xhtml", the bidirectional markup mechanisms specific to each format
147 SHOULD be used. The value of the "dir" attribute does define the
148 base directionality of Language-Sensitive text within Text Constructs
149 and atom:content elements regardless of the value of the type
150 attribute.
152 Example atom:feed with bidirectional XHTML:
154
155
156 ...
157
158
161
162 ...
163
165 Unicode bidirectional control characters MAY also be used within
166 attributes and element values to indicate the directionality of text
167 or to modify the default operation of the Bidirectional Algorithm.
168 Implementers are reminded that unexpected results could occur when
169 using both the "dir" attribute and the Unicode control characters
170 within a single document.
172 2.1. Direction Guessing
174 In Atom documents that do not contain a "dir" attribute, it is
175 possible to apply heuristics to guess the base directionality of text
176 in the document. Such heuristics can take into consideration the in-
177 scope language context established by the use of the xml:lang
178 attribute or an analysis of the directional properties of the Unicode
179 characters used within the text. Such guessing algorithms can
180 produce reasonably acceptable results in many cases but cannot be
181 guaranteed to produce correct results in every case. For this
182 reason, explicit determination of text direction using the "dir"
183 attribute is preferred over any guessing algorithm.
185 For compatibility with existing Atom documents that rely on direction
186 guessing, user agents MAY perform direction guessing in documents
187 that do not contain a "dir" attribute but they SHOULD NOT do so when
188 an in-scope "dir" attribute is provided.
190 3. Security Considerations
192 The security considerations discussed in [RFC4287] Section 8 apply.
194 4. IANA Considerations
196 No IANA actions are required by this document.
198 5. References
199 5.1. Normative References
201 [ISO10646]
202 International Organization for Standardization, "ISO/IEC
203 10646:2003: Information Technology - Universal Multiple-
204 Octet Coded Character Set (UCS)", December 2003.
206 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
207 Requirement Levels", BCP 14, RFC 2119, March 1997.
209 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
210 Syndication Format", RFC 4287, December 2005.
212 [UAX9] Davis, M., "Unicode Standard Annex #9: The Bidirectional
213 Algorithm", September 2006.
215 [W3C.REC-xml-infoset-20040204]
216 Cowan, J. and R. Tobin, "XML Information Set (Second
217 Edition)", World Wide Web Consortium Recommendation REC-
218 xml-infoset-20040204, February 2004,
219 .
221 [W3C.REC-xml-names-19990114]
222 Layman, A., Bray, T., and D. Hollander, "Namespaces in
223 XML", World Wide Web Consortium FirstEdition REC-xml-
224 names-19990114, January 1999,
225 .
227 5.2. Informative References
229 [RELAXNG] Clark, J., "RELAX NG Compact Syntax", December 2001,
230 .
233 [W3C.REC-html401-19991224]
234 Jacobs, I., Raggett, D., and A. Hors, "HTML 4.01
235 Specification", World Wide Web Consortium
236 Recommendation REC-html401-19991224, December 1999,
237 .
239 Appendix A. Acknowledgements
241 The author gratefully acknowledges the feedback from the Atom
242 Publishing Format and Protocol Working Group.
244 Author's Address
246 James M Snell
248 Email: jasnell@gmail.com
249 URI: http://www.snellspace.com
251 Full Copyright Statement
253 Copyright (C) The IETF Trust (2008).
255 This document is subject to the rights, licenses and restrictions
256 contained in BCP 78, and except as set forth therein, the authors
257 retain all their rights.
259 This document and the information contained herein are provided on an
260 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
261 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
262 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
263 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
264 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
265 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
267 Intellectual Property
269 The IETF takes no position regarding the validity or scope of any
270 Intellectual Property Rights or other rights that might be claimed to
271 pertain to the implementation or use of the technology described in
272 this document or the extent to which any license under such rights
273 might or might not be available; nor does it represent that it has
274 made any independent effort to identify any such rights. Information
275 on the procedures with respect to rights in RFC documents can be
276 found in BCP 78 and BCP 79.
278 Copies of IPR disclosures made to the IETF Secretariat and any
279 assurances of licenses to be made available, or the result of an
280 attempt made to obtain a general license or permission for the use of
281 such proprietary rights by implementers or users of this
282 specification can be obtained from the IETF on-line IPR repository at
283 http://www.ietf.org/ipr.
285 The IETF invites any interested party to bring to its attention any
286 copyrights, patents or patent applications, or other proprietary
287 rights that may cover technology that may be required to implement
288 this standard. Please address the information to the IETF at
289 ietf-ipr@ietf.org.
291 Acknowledgment
293 Funding for the RFC Editor function is provided by the IETF
294 Administrative Support Activity (IASA).