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 <div xmlns="http://www.w3.org/1999/xhtml"> 155 <p dir="rtl">ٹٺٻ</p> 156 </div> 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).