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