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