Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/internet-drafts/draft-accilent-at-sign-00.txt Дата изменения: Sat Jul 31 04:46:18 2010 Дата индексирования: Mon Oct 1 23:59:01 2012 Кодировка:

Internet Engineering Task Force R. Simpson
Internet-Draft Accilent Corp.
Intended status: Informational July 31, 2010
Expires: February 1, 2011


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.





Simpson Expires February 1, 2011 [Page 1]

Internet-Draft Proper Use of "@" July 2010


Table of Contents

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






































Simpson Expires February 1, 2011 [Page 2]

Internet-Draft Proper Use of "@" July 2010


1. Introduction

The original specification of the URI format is in RFC 3986
[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 [RFC2119].


2. Issues

o 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.

o 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?

o 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

o 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.

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



Simpson Expires February 1, 2011 [Page 3]

Internet-Draft Proper Use of "@" July 2010


4. Valid Syntax

In RFC 3986 [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 |
|----------------------------------|
| JohnDoe@ |
|__________________________________|

will be interpreted as:

+------------------------------------------------------------------+
| http://ExampleOnly.com/JaneSmith |
|------------------------------------------------------------------|
| JohnDoe@ExampleOnly |
|__________________________________________________________________|






Simpson Expires February 1, 2011 [Page 4]

Internet-Draft Proper Use of "@" July 2010


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!
@JohnDoe
ExampleOnly.com@JohnDoe


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?

Figure 1

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.

Figure 2







Simpson Expires February 1, 2011 [Page 5]

Internet-Draft Proper Use of "@" July 2010


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.

Figure 3


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

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.







Simpson Expires February 1, 2011 [Page 6]

Internet-Draft Proper Use of "@" July 2010


Author's Address

Robert Simpson
Accilent Corp.
P.O. Box 601
Lawrence, PA 15055
US

Phone: +1-412 337-3113
Email: RobS.rfc5@MailScreen.com









































Simpson Expires February 1, 2011 [Page 7]