Clarification of Proper Use of "@" (at sign) in URI-style Components
draft-accilent-at-sign-00

Abstract

Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on February 1, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
    1.1.  Requirements Language
2.  Issues
3.  Conclusions
4.  Valid Syntax
5.  Invalid Syntax
6.  Examples
7.  IANA Considerations
8.  Security Considerations
9.  Normative References
§  Author's Address

1.  Introduction

The original specification of the URI format is in RFC 3986 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986].

1.1.  Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Issues

• Microblogging systems on social networks have introduced a shortcut feature where short replies with tokens containing an "@" and userinfo are automatically converted to HTML links. On systems where the host component is assumed to be the same as the host that is currently loaded into the user's browser, the defacto standard syntax that has evolved for these auto-generated links is for the "@" (at sign) to precede the userinfo.
• Allowing the "@" to be placed in a non-standard location, especially in HTML links, results in confusion about which component follows the "@". For example, in "@its.me", is "its.me" the userinfo or the host component?
• How would the "@userinfo" syntax currently being used be extended to support multiple networks? For example, in a mobile application that allows posting updates to multiple social networks, should it conform to the defacto standard and use "ExampleOnly.com@userinfo" or go against the current common usage and try to conform to the standards for URIs instead? Either option introduces potentially harmful confusion for users and automated systems.

3.  Conclusions

• It should be allowable to omit the host component of the authority syntax when the host component is known, such as when referencing another user on the same host or relative to a base URI.
• Placing the "@" prior to the userinfo instead of following it should be explicitly prohibited due to the confusion it introduces and the security concerns due to possibly misinterpreting the userinfo and as a result of allowing users to become comfortable with misplacing the "@".

4.  Valid Syntax

In RFC 3986 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986], the syntax of the authority component in a URI is defined as:

            authority   = [ userinfo "@" ] host [ ":" port ]

In addition, when the user is on a known host, on the same social network for example, the host and port components MAY be omitted:

            authority   = [ userinfo "@" ] [ host [ ":" port ] ]

When the host component is omitted, the userinfo component will be interpreted to be relative to the base URI of the current resource. For example:

+--------------------------------------------------+
| http://ExampleOnly.com/JaneSmith                 |
|--------------------------------------------------|
| JohnDoe@ I will meet you there in a short while. |
|__________________________________________________|

will be interpreted as:

+-----------------------------------------------------------------+
| http://ExampleOnly.com/JaneSmith                                |
|-----------------------------------------------------------------|
| JohnDoe@ExampleOnly.com I will meet you there in a short while. |
|_________________________________________________________________|

and (in HTML code):

+----------------------------------+
| http://ExampleOnly.com/JaneSmith |
|----------------------------------|
| <a href="/JohnDoe">JohnDoe@</a>  |
|__________________________________|

will be interpreted as:

+------------------------------------------------------------------+
| http://ExampleOnly.com/JaneSmith                                 |
|------------------------------------------------------------------|
| <a href="http://ExampleOnly.com/JohnDoe">JohnDoe@ExampleOnly</a> |
|__________________________________________________________________|

5.  Invalid Syntax

In a component that may at some time be interpreted to be a URI by some system the "@" MUST NOT be placed prior to the userinfo component:

                      WRONG! [ "@" userinfo ]

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 "@" SHOULD NOT appear in an improper location in an HTML link:

                                  WRONG!
           <a href="http://ExampleOnly.com/JohnDoe">@JohnDoe</a>
    <a href="http://ExampleOnly.com/JohnDoe">ExampleOnly.com@JohnDoe</a>

6.  Examples

Improper usage when user being replied to is on the same social network

+--------------------------------------------------+
| @JohnDoe I will meet you there in a short while. |
|__________________________________________________|

WRONG! How would the host component be appended if the user was on a different network?

Standalone userinfo component when user being replied to is on the same social network

+--------------------------------------------------+
| JohnDoe@ I will meet you there in a short while. |
|__________________________________________________|

This follows the current standard use of "@" in the authority component.

Fully-qualified authority component when the user being replied to can be on a different host

+-----------------------------------------------------------------+
| JohnDoe@ExampleOnly.com I will meet you there in a short while. |
|_________________________________________________________________|

Appending the host component after the "@" results in syntax that conforms to the RFC 3986.

7.  IANA Considerations

This memo includes no request to IANA.

8.  Security Considerations

A URI does not in itself pose a security threat. However, as URIs are often used to provide a compact set of instructions for access to network resources, care must be taken to properly interpret the data within a URI, to prevent that data from causing unintended access, and to avoid including data that should not be revealed in plain text.

However, placing an "@" in the wrong position, such as prior to the userinfo rather than following it, can introduce security risks, since the userinfo may be incorrectly interpreted or supplied to unauthorized systems. A defacto standard that places the "@" in the wrong location introduces additional security risks due to the increased likelihood that users will misplace the "@" as a result of the confusion.

9. Normative References

Author's Address