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