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