idnits 2.17.1
draft-snell-atompub-bidi-03.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 248.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 259.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 266.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 272.
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 (March 19, 2007) is 6241 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 March 19, 2007
4 Intended status: Standards Track
5 Expires: September 20, 2007
7 Atom Bidirectional Attribute
8 draft-snell-atompub-bidi-03.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 September 20, 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 the "dir" attribute is not specified, the value is
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 Example atom:feed with right-to-left directionality
116
117
118 ٹٺٻ
119 ...
120
122 If an Atom document contains any right-to-left characters, the
123 Unicode Bidirectional Algorithm [UNI9] SHOULD be used to render that
124 text. Because consumers of Atom documents vary broadly in the way
125 they display text, the "ltr" and "rtl" values do not necessarily open
126 an additional level of embedding with respect to the bidirectional
127 algorithm. Consuming applications that render bidirectional text are
128 responsible for determining the appropriate level of embedding. If
129 the dir attribute value is "rtl", Atom processors that display
130 affected text MAY choose to right-align that text as per the rules
131 described in Section 8 of [W3C.REC-html401-19991224].
133 When Atom Text Constructs or the atom:content elements contain
134 bidirectional text and the type attribute value is either "html" or
135 "xhtml", the bidirectional markup mechanisms specific to each format
136 SHOULD be used. The value of the "dir" attribute does define the
137 base directionality of Language-Sensitive text within Text Constructs
138 and atom:content elements regardless of the value of the type
139 attribute.
141 Example atom:feed with bidirectional XHTML:
143
144
145
146
149
150 ...
151
153 Unicode bidirectional control characters MAY also be used within
154 attributes and element values to indicate the directionality of text
155 or to modify the default operation of the Bidirectional Algorithm.
157 Implementers are reminded that unexpected results could occur when
158 using both the "dir" attribute and the Unicode control characters
159 within a single document.
161 2.1. Direction Guessing
163 In Atom documents that do not contain a "dir" attribute, it is
164 possible to apply heuristics to guess the base directionality of text
165 in the document. Such heuristics can take into consideration the in-
166 scope language context established by the use of the xml:lang
167 attribute or an analysis of the directional properties of the Unicode
168 characters used within the documents text. Such guessing algorithms
169 can produce reasonably acceptable results in many cases but cannot be
170 guaranteed to produce correct results in every case. For this
171 reason, explicit determination of text direction using the "dir"
172 attribute SHOULD be preferred over any guessing algorithm.
174 3. Security Considerations
176 The security considerations discussed in [RFC4287] Section 8 apply.
178 4. IANA Considerations
180 No IANA actions are required by this document.
182 5. References
184 5.1. Normative References
186 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
187 Requirement Levels", BCP 14, RFC 2119, March 1997.
189 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
190 Syndication Format", RFC 4287, December 2005.
192 [UNI9] Davis, M., "The Bidirectional Algorithm", March 2004.
194 [UNICODE] International Organization for Standardization, "ISO/IEC
195 10646:2003: Information Technology - Universal Multiple-
196 Octet Coded Character Set (UCS)", December 2003.
198 [W3C.REC-xml-infoset-20040204]
199 Cowan, J. and R. Tobin, "XML Information Set (Second
200 Edition)", World Wide Web Consortium Recommendation REC-
201 xml-infoset-20040204, February 2004,
202 .
204 [W3C.REC-xml-names-19990114]
205 Layman, A., Hollander, D., and T. Bray, "Namespaces in
206 XML", World Wide Web Consortium FirstEdition REC-xml-
207 names-19990114, January 1999,
208 .
210 5.2. Informative References
212 [RELAXNG] Clark, J., "RELAX NG Compact Syntax", December 2001,
213 .
216 [W3C.REC-html401-19991224]
217 Jacobs, I., Hors, A., and D. Raggett, "HTML 4.01
218 Specification", World Wide Web Consortium
219 Recommendation REC-html401-19991224, December 1999,
220 .
222 Appendix A. Acknowledgements
224 The author gratefully acknowledges the feedback from the Atom
225 Publishing Format and Protocol Working Group.
227 Author's Address
229 James M Snell
231 Email: jasnell@gmail.com
232 URI: http://www.snellspace.com
234 Full Copyright Statement
236 Copyright (C) The IETF Trust (2007).
238 This document is subject to the rights, licenses and restrictions
239 contained in BCP 78, and except as set forth therein, the authors
240 retain all their rights.
242 This document and the information contained herein are provided on an
243 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
244 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
245 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
246 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
247 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
248 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
250 Intellectual Property
252 The IETF takes no position regarding the validity or scope of any
253 Intellectual Property Rights or other rights that might be claimed to
254 pertain to the implementation or use of the technology described in
255 this document or the extent to which any license under such rights
256 might or might not be available; nor does it represent that it has
257 made any independent effort to identify any such rights. Information
258 on the procedures with respect to rights in RFC documents can be
259 found in BCP 78 and BCP 79.
261 Copies of IPR disclosures made to the IETF Secretariat and any
262 assurances of licenses to be made available, or the result of an
263 attempt made to obtain a general license or permission for the use of
264 such proprietary rights by implementers or users of this
265 specification can be obtained from the IETF on-line IPR repository at
266 http://www.ietf.org/ipr.
268 The IETF invites any interested party to bring to its attention any
269 copyrights, patents or patent applications, or other proprietary
270 rights that may cover technology that may be required to implement
271 this standard. Please address the information to the IETF at
272 ietf-ipr@ietf.org.
274 Acknowledgment
276 Funding for the RFC Editor function is provided by the IETF
277 Administrative Support Activity (IASA).