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

The original specification of the URI format is in RFC 3986.

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.

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.

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 "@".

In RFC 3986, the syntax of the authority component in a URI is defined as:

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:

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:

will be interpreted as:

and (in HTML code):

JohnDoe@ | |__________________________________| ]]> will be interpreted as:

JohnDoe@ExampleOnly | |__________________________________________________________________| ]]>

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:

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:

@JohnDoe ExampleOnly.com@JohnDoe ]]>

Improper usage when user being replied to is on the same social network 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 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 Appending the host component after the "@" results in syntax that conforms to the RFC 3986.

This memo includes no request to IANA.

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.