idnits 2.17.1
draft-snell-atompub-bidi-00.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 14.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 248.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 225.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 232.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 238.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 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 (September 2006) is 6427 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: 3 errors (**), 0 flaws (~~), 2 warnings (==), 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 September 2006
4 Expires: March 5, 2007
6 Atom Bidirectional Extension
7 draft-snell-atompub-bidi-00.txt
9 Status of this Memo
11 By submitting this Internet-Draft, each author represents that any
12 applicable patent or other IPR claims of which he or she is aware
13 have been or will be disclosed, and any of which he or she becomes
14 aware will be disclosed, in accordance with Section 6 of BCP 79.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as Internet-
19 Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt.
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 This Internet-Draft will expire on March 5, 2007.
34 Copyright Notice
36 Copyright (C) The Internet Society (2006).
38 Abstract
40 This document describes an extension to the Atom format that can be
41 used to define the base directionality of directionally-neutral
42 characters contained within an Atom document.
44 Table of Contents
46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
47 1.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . . 3
48 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 3
49 2. The "u:dir" Attribute . . . . . . . . . . . . . . . . . . . . . 3
50 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
51 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
52 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
53 5.1. Normative References . . . . . . . . . . . . . . . . . . . 5
54 5.2. Informative References . . . . . . . . . . . . . . . . . . 6
55 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6
56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
57 Intellectual Property and Copyright Statements . . . . . . . . . . 8
59 1. Introduction
61 This document describes an extension to the Atom format [RFC4287]
62 that can be used to define the base directionality of directionally-
63 neutral characters contained within an Atom document.
65 1.1. Namespace
67 The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML
68 elements and attributes described in this specification is
69 http://purl.org/atompub/bidi
71 In this document, the namespace prefix "u:" is used for the above
72 Namespace URI. Note that the choice of namespace prefix is arbitrary
73 and not semantically significant.
75 1.2. Notational Conventions
77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
79 document are to be interpreted as described in BCP 14, [RFC2119].
81 This extension is, like the Atom Syndication Format [RFC4287] itself,
82 specified using terms from the XML Infoset [W3C.REC-xml-infoset-
83 20040204]. However, this specification uses a shorthand form for two
84 commons terms: The phrase "Information Item" is omitted when naming
85 Element and Attribute Information Items. Therefore, when this
86 specification uses the term "element," it is referring to an Element
87 Information Item in Infoset terms. Likewise, when it uses the term
88 "attribute," it is referring to an Attribute Information Item.
90 Some sections of this specification are illustrated with fragments of
91 a non-normative RELAX NG Compact schema [RELAXNG]. However, the text
92 of this specification provides the sole definition of conformance.
94 2. The "u:dir" Attribute
96 The "u:dir" attribute specifies the base direction of directionally-
97 neutral text [UNICODE]. Possible values for the attribute are "ltr"
98 and "rtl" indicating "left-to-right" and "right-to-left"
99 respectively, "lro" and "rlo" indicating explicit "left-to-right" and
100 "right-to-left" overrides, or an empty string indicating that no
101 base-direction is specified. If the "u:dir" attribute is not
102 specified, the value is assumed to be an empty string. The attribute
103 can appear anywhere in an Atom document, except where it is
104 explicitly forbidden.
106 dir = attribute u:dir { "ltr" | "rtl" | "lro" | "rlo" | "" }
108 The direction specified by "u:dir" applies only to elements and
109 attributes whose values are specified as being "Language-Sensitive"
110 as defined by Section 2 of [RFC4287]. The attribute is inherited by
111 descendent elements and may be overridden.
113 Example atom:feed with right-to-left directionality
115
116
118 ٹٺٻ
119 ...
120
122 If an Atom document contains any right-to-left characters, the
123 Unicode Bidirectional Algorithm [UNI9] MUST 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.
130 The "lro" and "rlo" values override the inherent directionality of
131 characters as defined by [UNICODE]. When used, affected text MUST be
132 rendered as if preceded by either Unicode character U+202D (left-to-
133 right override) or U+202E (right-to-left override) and followed by
134 U+202C (pop directional formatting).
136 When Atom Text Constructs or the atom:content elements contain
137 bidirectional text and the type attribute is set to either "html" or
138 "xhtml", the bidirectional markup mechanisms specific to each format
139 SHOULD be used. The value of the "u:dir" attribute does define the
140 base directionality of Language-Sensitive text within Text Constructs
141 and atom:content elements regardless of the value of the type
142 attribute.
144 Example atom:feed with bidirectional XHTML:
146
147
149
150
153
154 ...
155
157 The Unicode bidirectional control characters MAY also be used within
158 attributes and element values to indicate the directionality of text.
159 Implementers are reminded that unexpected results could occur when
160 using both the "u:dir" attribute and the Unicode control characters
161 within a single document.
163 3. Security Considerations
165 The security considerations discussed in [RFC4287] Section 8 apply.
167 4. IANA Considerations
169 No IANA actions are required by this document.
171 5. References
173 5.1. Normative References
175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
176 Requirement Levels", BCP 14, RFC 2119, March 1997.
178 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
179 Syndication Format", RFC 4287, December 2005.
181 [UNI9] Davis, M., "The Bidirectional Algorithm", March 2004.
183 [UNICODE] International Organization for Standardization, "ISO/IEC
184 10646:2003: Information Technology - Universal Multiple-
185 Octet Coded Character Set (UCS)", December 2003.
187 [W3C.REC-xml-infoset-20040204]
188 Cowan, J. and R. Tobin, "XML Information Set (Second
189 Edition)", World Wide Web Consortium Recommendation REC-
190 xml-infoset-20040204, February 2004,
191 .
193 [W3C.REC-xml-names-19990114]
194 Layman, A., Bray, T., and D. Hollander, "Namespaces in
195 XML", World Wide Web Consortium Recommendation REC-xml-
196 names-19990114, January 1999,
197 .
199 5.2. Informative References
201 [RELAXNG] Clark, J., "RELAX NG Compact Syntax", December 2001, .
205 Appendix A. Acknowledgements
207 TBD
209 Author's Address
211 James M Snell
213 Email: jasnell@gmail.com
214 URI: http://www.snellspace.com
216 Intellectual Property Statement
218 The IETF takes no position regarding the validity or scope of any
219 Intellectual Property Rights or other rights that might be claimed to
220 pertain to the implementation or use of the technology described in
221 this document or the extent to which any license under such rights
222 might or might not be available; nor does it represent that it has
223 made any independent effort to identify any such rights. Information
224 on the procedures with respect to rights in RFC documents can be
225 found in BCP 78 and BCP 79.
227 Copies of IPR disclosures made to the IETF Secretariat and any
228 assurances of licenses to be made available, or the result of an
229 attempt made to obtain a general license or permission for the use of
230 such proprietary rights by implementers or users of this
231 specification can be obtained from the IETF on-line IPR repository at
232 http://www.ietf.org/ipr.
234 The IETF invites any interested party to bring to its attention any
235 copyrights, patents or patent applications, or other proprietary
236 rights that may cover technology that may be required to implement
237 this standard. Please address the information to the IETF at
238 ietf-ipr@ietf.org.
240 Disclaimer of Validity
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 AND THE INTERNET
245 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
246 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
247 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
248 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
250 Copyright Statement
252 Copyright (C) The Internet Society (2006). This document is subject
253 to the rights, licenses and restrictions contained in BCP 78, and
254 except as set forth therein, the authors retain all their rights.
256 Acknowledgment
258 Funding for the RFC Editor function is currently provided by the
259 Internet Society.