idnits 2.17.1 draft-accilent-at-sign-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The "@" SHOULD not be placed prior to the userinfo component even in areas of plain text due to the potential for altering users' perception of the correct placement of the "@" separator. -- The document date (July 31, 2010) is 5018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Simpson 3 Internet-Draft Accilent Corp. 4 Intended status: Informational July 31, 2010 5 Expires: February 1, 2011 7 Clarification of Proper Use of "@" (at sign) in URI-style Components 8 draft-accilent-at-sign-00 10 Abstract 12 Defacto standards have evolved that conflict with existing standards, 13 specifically RFC 3986. This document clarifies the use of the "@" 14 (at sign) in URIs and partial URI-like addresses. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on February 1, 2011. 33 Copyright Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 52 2. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Valid Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Invalid Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 56 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 59 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 The original specification of the URI format is in RFC 3986 65 [RFC3986]. 67 1.1. Requirements Language 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [RFC2119]. 73 2. Issues 75 o Microblogging systems on social networks have introduced a 76 shortcut feature where short replies with tokens containing an "@" 77 and userinfo are automatically converted to HTML links. On 78 systems where the host component is assumed to be the same as the 79 host that is currently loaded into the user's browser, the defacto 80 standard syntax that has evolved for these auto-generated links is 81 for the "@" (at sign) to precede the userinfo. 83 o Allowing the "@" to be placed in a non-standard location, 84 especially in HTML links, results in confusion about which 85 component follows the "@". For example, in "@its.me", is "its.me" 86 the userinfo or the host component? 88 o How would the "@userinfo" syntax currently being used be extended 89 to support multiple networks? For example, in a mobile 90 application that allows posting updates to multiple social 91 networks, should it conform to the defacto standard and use 92 "ExampleOnly.com@userinfo" or go against the current common usage 93 and try to conform to the standards for URIs instead? Either 94 option introduces potentially harmful confusion for users and 95 automated systems. 97 3. Conclusions 99 o It should be allowable to omit the host component of the authority 100 syntax when the host component is known, such as when referencing 101 another user on the same host or relative to a base URI. 103 o Placing the "@" prior to the userinfo instead of following it 104 should be explicitly prohibited due to the confusion it introduces 105 and the security concerns due to possibly misinterpreting the 106 userinfo and as a result of allowing users to become comfortable 107 with misplacing the "@". 109 4. Valid Syntax 111 In RFC 3986 [RFC3986], the syntax of the authority component in a URI 112 is defined as: 114 authority = [ userinfo "@" ] host [ ":" port ] 116 In addition, when the user is on a known host, on the same social 117 network for example, the host and port components MAY be omitted: 119 authority = [ userinfo "@" ] [ host [ ":" port ] ] 121 When the host component is omitted, the userinfo component will be 122 interpreted to be relative to the base URI of the current resource. 123 For example: 125 +--------------------------------------------------+ 126 | http://ExampleOnly.com/JaneSmith | 127 |--------------------------------------------------| 128 | JohnDoe@ I will meet you there in a short while. | 129 |__________________________________________________| 131 will be interpreted as: 133 +-----------------------------------------------------------------+ 134 | http://ExampleOnly.com/JaneSmith | 135 |-----------------------------------------------------------------| 136 | JohnDoe@ExampleOnly.com I will meet you there in a short while. | 137 |_________________________________________________________________| 139 and (in HTML code): 141 +----------------------------------+ 142 | http://ExampleOnly.com/JaneSmith | 143 |----------------------------------| 144 | JohnDoe@ | 145 |__________________________________| 147 will be interpreted as: 149 +------------------------------------------------------------------+ 150 | http://ExampleOnly.com/JaneSmith | 151 |------------------------------------------------------------------| 152 | JohnDoe@ExampleOnly | 153 |__________________________________________________________________| 155 5. Invalid Syntax 157 In a component that may at some time be interpreted to be a URI by 158 some system the "@" MUST NOT be placed prior to the userinfo 159 component: 161 WRONG! [ "@" userinfo ] 163 The "@" SHOULD not be placed prior to the userinfo component even in 164 areas of plain text due to the potential for altering users' 165 perception of the correct placement of the "@" separator. 167 The "@" SHOULD NOT appear in an improper location in an HTML link: 169 WRONG! 170 @JohnDoe 171 ExampleOnly.com@JohnDoe 173 6. Examples 175 Improper usage when user being replied to is on the same social 176 network 178 +--------------------------------------------------+ 179 | @JohnDoe I will meet you there in a short while. | 180 |__________________________________________________| 182 WRONG! How would the host component be appended if the user was on a 183 different network? 185 Figure 1 187 Standalone userinfo component when user being replied to is on the 188 same social network 190 +--------------------------------------------------+ 191 | JohnDoe@ I will meet you there in a short while. | 192 |__________________________________________________| 194 This follows the current standard use of "@" in the authority 195 component. 197 Figure 2 199 Fully-qualified authority component when the user being replied to 200 can be on a different host 202 +-----------------------------------------------------------------+ 203 | JohnDoe@ExampleOnly.com I will meet you there in a short while. | 204 |_________________________________________________________________| 206 Appending the host component after the "@" results in syntax that 207 conforms to the RFC 3986. 209 Figure 3 211 7. IANA Considerations 213 This memo includes no request to IANA. 215 8. Security Considerations 217 A URI does not in itself pose a security threat. However, as URIs 218 are often used to provide a compact set of instructions for access to 219 network resources, care must be taken to properly interpret the data 220 within a URI, to prevent that data from causing unintended access, 221 and to avoid including data that should not be revealed in plain 222 text. 224 However, placing an "@" in the wrong position, such as prior to the 225 userinfo rather than following it, can introduce security risks, 226 since the userinfo may be incorrectly interpreted or supplied to 227 unauthorized systems. A defacto standard that places the "@" in the 228 wrong location introduces additional security risks due to the 229 increased likelihood that users will misplace the "@" as a result of 230 the confusion. 232 9. Normative References 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, March 1997. 237 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 238 Resource Identifier (URI): Generic Syntax", STD 66, 239 RFC 3986, January 2005. 241 Author's Address 243 Robert Simpson 244 Accilent Corp. 245 P.O. Box 601 246 Lawrence, PA 15055 247 US 249 Phone: +1-412 337-3113 250 Email: RobS.rfc5@MailScreen.com