[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Simple] New WG charter topic: draft-aoki-feel-00.txt ?
Guys,
We know that SIMPLE is overloaded with work, but lately we came across a
new topic that seems to be crucial for standardization - especially for
the benefit of the growing IM communications.
We wrote a draft that highlights the problem and introduces some
solutions. These are initial thoughts only. You will see that many areas
(such as the security considerations) need to be thought through in more
details. Before we invest more efforts and submit the draft to the IETF,
we wanted to share our thoughts and get your feedback regarding the
validity of this direction in general.
Thanks a lot,
The authors.
Network Working Group E. Aoki
Internet-Draft America Online, Inc.
Expires: October 3, 2005 O. Levin
T. Rang
M. Trommsdorff
Microsoft Corporation
April 2005
FEEL - The Federated Emoticon and Expression Language
draft-aoki-feel-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 3, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a set of standard conventions for emoticons,
also known as "smileys", that allow messaging systems from different
vendors to convey text-based expressions interoperably. The
Aoki, et al. Expires October 3, 2005 [Page 1]
Internet-Draft FEEL April 2005
emoticons defined in this document can be conveyed over any
text-based messaging protocol, including email, instant messaging,
ntalk, and others.
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Basic Emoticons . . . . . . . . . . . . . . . . . . . . . 5
4.2 Extended Emoticons . . . . . . . . . . . . . . . . . . . . 5
4.3 Inanimate Objects . . . . . . . . . . . . . . . . . . . . 6
4.4 Specialized Emoticons . . . . . . . . . . . . . . . . . . 6
4.5 Translations . . . . . . . . . . . . . . . . . . . . . . . 6
4.5.1 Locale Specific Translations . . . . . . . . . . . . . 7
4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Augmented BNF for FEEL compliant emoticons . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1 Normative References . . . . . . . . . . . . . . . . . . . 10
8.2 Informational References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 12
Aoki, et al. Expires October 3, 2005 [Page 2]
Internet-Draft FEEL April 2005
1. Conventions
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 [1].
2. Background
Each day, millions of people around the world exchange literally
billions of emails, instant messages, and other forms of text-based,
computer mediated communication via the Internet. Although
originally designed to facilitate academic research, today's Internet
messaging systems are used within enterprises, families, and social
groups as a fast, efficient form of communication.
As the user base for messaging systems grew, so, too, did
misunderstandings between and among user groups. Deprived of the
cues provided through vocal inflection or personal interaction,
messaging users found it difficult to discern the tone or intent of
specific messages or message exchanges. The complex emotions that
underlie sarcasm, joking, anger, and affection, just to name a few,
were neutralized in these text based messaging formats and often
resulted in misinterpretation or embarrassment.
Over time, emoticons were devised to fill this gap and to enable
Internet users to express emotions through text-based messaging
systems [3]. Emoticons are a series of text-based characters which,
when viewed on their side, form a picture that is understood to
convey a particular emotion.
The most common of these emoticons is the "smiley," consisting of the
ASCII characters 0x3A, 0x2D, and 0x29. When displayed, these
characters together appear like this:
:-)
Figure 1
which is often used to indicate that a preceding comment is humorous
in nature.
Soon, users devised ever more elaborate forms of emoticons to
represent a wider variety of emotions. The following examples
represent crying, winking, and sticking out one's tongue, for
example.
:'( ;-) :-P
Aoki, et al. Expires October 3, 2005 [Page 3]
Internet-Draft FEEL April 2005
Figure 2
The growing array of emoticons sometimes made it difficult for users
to understand what emotion a given series of characters was supposed
to represent, so some messaging user agents, when rendering text
containing an emoticon began to replace the characters representing
the emoticon with a graphically rendered static icon that would be
displayed in their place. On the composition side, these user agents
often provided a menu or other user interface element that allowed
users to select an emotion graphically from a list, substituting the
appropriate textual representations for on-the-wire rendering of the
expression. Many of today's commercial instant messaging clients,
for example, include menus of a dozen or more emoticons that users
can insert into their conversations.
3. Motivation
However, these user agent manipulations, although convenient for
users, come at the price of interoperability. As vendors create
systems that interoperate with one another, or that bridge various
different forms of text based communications (e.g., mail and IM), the
potential for emoticon confusion once again exists, since the
endpoints are making independent decisions of the semantics of a
string of characters.
Just recently, with the upcoming roll out of the enterprise to public
IM connectivity services, the involved parties came to realize that
in addition to the well-defined standard transport, security,
signaling, presence, and IM means (for details see Inter-domain
Requirements for SIP/SIMPLE [4]), no less consideration needed to be
invested into normalizing the expressions and emotions being used so
extensively in IM communications today.
Take, for example, the emoticon consisting of the characters: 0x3A,
0x2D, and 0x2A, or:
:-*
Figure 3
One commercial instant messaging client might display for these
characters an icon that indicates a user whispering, while another
might show a user kissing. To a user who selected "whisper" from a
palette of emotions to represent in a sent message, the receiver's
interpretation that the sender had wanted to send a kiss would be
amusing at best and highly inappropriate at worst, with potentially
significant emotional and commercial implications.
Aoki, et al. Expires October 3, 2005 [Page 4]
Internet-Draft FEEL April 2005
In order to mitigate these effects, the authors propose FEEL, the
Federated Emoticon and Expression Language, which proposes a standard
for expressing and interpreting emoticons in text-based messaging.
4. Specification
This specification defines several emotional expressions in text
communications. These emotions are specified by text patterns that
are interpreted by the messaging endpoint as being equivalent to a
certain graphical representation. Several common emotions are
supported across most federated domains. Because of differences in
the typical user in various communications systems, many additional
emotions (along with activities and other expressions) are supported
that may not necessarily translate well across the federated
boundary.
4.1 Basic Emoticons
All FEEL compliant systems MUST support the following emotions via
emoticons- happy, sad, winking, and confused. These emotions are the
most basic that can be expressed in conversation, regardless of the
type of conversation. Each of these emotions MUST be represented
with a graphical representation of a face. That face SHOULD NOT
convey any feelings in addition to happiness that may be
misinterpreted by the peer. Examples of additional emotions are
sarcasm or skepticism (smirk), laughing or winking.
4.2 Extended Emoticons
In addition to the basic emoticons, there are several emotions and
activities that a FEEL compliant system may wish to convey. These
emoticons allow users to fine tune the emotion being expressed. The
emoticons are specified either because they are common across most
conversations regardless of type, or they represent unique feelings
that should not be misinterpreted as opposing emotions. "In love" is
a prime example of why extended emoticons must not be misinterpreted.
If a user in a corporate setting sends a message with a "whispering"
emoticon, and the receiver of that message is using a client in a
social network which treats this ASCII string as "kissing" or "in
love", the translation can create potential personal or legal
complications for the sender. Applications SHOULD either support or
at least understand (regardless of whether it is rendered) emoticons
representing the following:
Aoki, et al. Expires October 3, 2005 [Page 5]
Internet-Draft FEEL April 2005
Emotions
-------------------
Laughing
Surprised
Angry
Feeling silly
Crying
In love
Feeling innocent or angelic
Activities
--------------------
Ill
Asleep or Bored
Not talking or Refuse to say
4.3 Inanimate Objects
Some messaging systems use emoticon support to render objects that do
not represent any emotion at all. While not containing a face, these
objects implicitly represent activities of a user. A FEEL compliant
system MAY support the following inanimate object emoticons- coffee,
package or gift, alcoholic beverage, and phone.
4.4 Specialized Emoticons
Beyond the common conversational emoticons, some systems may wish to
express emotions and activities that are unique to specific
communications. A FEEL compliant system MAY support emoticons not
otherwise defined in this specification. Any emotion expressed with
a proprietary emoticon MUST be registered with IANA to prevent
conflicting emotions.
4.5 Translations
In some cases, a perfect translation may not exist between two FEEL
compliant systems. When no direct translation is available, a system
MAY display a different emoticon if that emoticon represents the same
general range of emotion or related activity. Any emoticon
translation MUST present the same meaning or extract meaning rather
than add. For example, a toothy grin (very happy) MAY be translated
to smiley (happy). However smiley does not translate to toothy grin.
Similarly, translations applied to inanimate objects MUST relay the
same or similar information provided by the sender. For example, a
gift may be represented as a package, but a package may not
represented as a gift.
Aoki, et al. Expires October 3, 2005 [Page 6]
Internet-Draft FEEL April 2005
If a system cannot provide a similar representation to that expressed
by the sender, the receiving system MUST present the content as text,
thus allowing the user to interpret the text as best as possible.
Examples of similar (and dissimilar) representations are:
Similar: heart and kiss(both love), smiley and smiling angel(both
nice).
Dissimilar: kiss and telling a secret (inadvertently inappropriate),
beer and coffee (one is alcoholic, the other is not).
4.5.1 Locale Specific Translations
There are some cases where an emoticon expressed by a user in one
region may not have the same meaning to the other user who resides in
a different region. In this case, translations MAY also be performed
on emoticons for purpose of localization, provided it does not change
the general intent of the sender. Examples of this type of
translation are:
+----------------------+----------------------+-----------------------+
| Sender localized | Culture neutralized | Receiver localized |
| | (standard encoding) | |
+----------------------+----------------------+-----------------------+
| USA- Chugging a beer | Having a drink | France- Drinking wine |
+----------------------+----------------------+-----------------------+
| U.K- Playing darts | Engaging in a game | India- Playing cricket|
| | or sport | |
+----------------------+----------------------+-----------------------+
| Texas- Wearing a | Wearing a head | Boston- Wearing a |
| cowboy hat | garment | Red Sox cap |
+----------------------+----------------------+-----------------------+
4.6 Summary
The following table provides the set of known emoticons that MAY be
supported by an instant message system. Each emoticon description is
accompanied by a description, support requirement, and
supported/unsupported translations.
+----------+---------------+--------------+-----------+---------------+
| Emoticon | Description | Supported | MAY equal | MUST NOT equal|
+----------+---------------+--------------+-----------+---------------+
| :-) | Happy | MUST | None | Sad, worried, |
| | | | | or angry |
+----------+---------------+--------------+-----------+---------------+
Aoki, et al. Expires October 3, 2005 [Page 7]
Internet-Draft FEEL April 2005
| :-( | Sad | MUST | None | Happy |
+----------+---------------+--------------+-----------+---------------+
| ;-) | Winking | MUST | None | Any |
+----------+---------------+--------------+-----------+---------------+
| :-/ | Confused or | | | Happy, Sad, |
| | worried | MUST | None | Winking |
+----------+---------------+--------------+-----------+---------------+
| :-)) | Laughing | SHOULD | Happy | Sad, Angry |
+----------+---------------+--------------+-----------+---------------+
| :-O | Surprised | SHOULD | Confused | Sad, Angry |
+----------+---------------+--------------+-----------+---------------+
| :@ | Angry | SHOULD | Sad | Happy, Winking|
+----------+---------------+--------------+-----------+---------------+
| :-P | Tongue out, | | | |
| | silly | SHOULD | Happy | Sad, Angry |
+----------+---------------+--------------+-----------+---------------+
| :-* | In love | SHOULD | Happy | Whisper,Angry,|
| | | | | Sad, Confused |
+----------+---------------+--------------+-----------+---------------+
| O:-) | Innocent or | | | |
| | angelic | SHOULD | Happy | Angry |
+----------+---------------+--------------+-----------+---------------+
| +o( | Feeling ill | | | |
| | or sick | SHOULD | Sad | In love |
+----------+---------------+--------------+-----------+---------------+
| |-) | Asleep / bored| SHOULD | Sad | None |
+----------+---------------+--------------+-----------+---------------+
| :-X | Not talking | SHOULD | None | Laughing |
+----------+---------------+--------------+-----------+---------------+
| :'( | Crying | SHOULD | Sad | Laughing |
+----------+---------------+--------------+-----------+---------------+
| :-D | Toothy grin | MAY | Happy | Sad, Angry |
+----------+---------------+--------------+-----------+---------------+
| 8-) | Feeling or | | | |
| | looking cool | MAY | Happy | None |
+----------+---------------+--------------+-----------+---------------+
| (C) | Coffee | MAY | None | Alcoholic |
| | | | | beverage |
+----------+---------------+--------------+-----------+---------------+
| (G) | Package | MAY | None | None |
+----------+---------------+--------------+-----------+---------------+
| (D) | Having a | | | |
| | drink | MAY | None | Coffee |
+----------+---------------+--------------+-----------+---------------+
| <):) | Wearing a head| MAY | Happy | Feeling or |
| | garment | | | looking cool |
+----------+---------------+--------------+-----------+---------------+
Aoki, et al. Expires October 3, 2005 [Page 8]
Internet-Draft FEEL April 2005
5. Augmented BNF for FEEL compliant emoticons
All of the mechanisms specified in this document are described in
both prose and an augmented Backus-Naur Form (BNF) defined in
RFC-2234 [2]. Section 6.1 of RFC 2234 defines a set of core rules
that are used by this specification, and not repeated here.
Implementers need to be familiar with the notation and content of RFC
2234 in order to understand this specification. Certain basic rules
are in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc.
Angle brackets are used within definitions to clarify the use of rule
names.
Happy = ( ":-)" / ":)" )
Sad = ( ":-(" / ":(" )
Winking = ( ";-)" / ";)" )
Confused = ( ":-/" / ":-s" )
Laughing = ":-))"
Surprised = ":-O"
Angry = ( ":@" / "X-(" )
Feeling silly = :-P
In love = ":-*"
Innocent = "O:-)"
Ill = "+o("
Asleep = "|-)"
Not talking = ":-X"
Crying = ":'("
Toothy grin = ( ":-D" / ":D" )
Cool = "8-)"
Coffee = "(C)"
Package = "(G)"
Having a drink = "(D)"
6. Security Considerations
This document does not introduce any new security issues beyond those
that apply to the protocols and transports over which emoticons are
delivered. However, it is the belief of the authors that having a
standard format for emoticons will result in increased precision of
communications between users, which should reduce the risk of
misinterpretation or embarrassments.
7. IANA Considerations
Future versions of this document will establish a FEEL IANA registry
which will allow applications to register application-specific
emoticons.
Aoki, et al. Expires October 3, 2005 [Page 9]
Internet-Draft FEEL April 2005
8. References
8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
8.2 Informational References
[3] Fahlman, S., "Smiley Lore :-)",
<http://www-2.cs.cmu.edu/~sef/sefSmiley.htm>.
[4] Levin, O., "Inter-domain Requirements for SIMPLE",
Internet-Draft draft-levin-simple-interdomain-reqs-02, February
2005.
Authors' Addresses
Edwin Aoki
America Online, Inc.
360 W. Caribbean Drive
Sunnyvale, CA 94089
USA
Email: aoki at aol.net
Orit Levin
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Email: oritl at microsoft.com
Tim Rang
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Email: timrang at microsoft.com
Aoki, et al. Expires October 3, 2005 [Page 10]
Internet-Draft FEEL April 2005
Michael Trommsdorff
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Email: mtromm at microsoft.com
Aoki, et al. Expires October 3, 2005 [Page 11]
Internet-Draft FEEL April 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr at ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Aoki, et al. Expires October 3, 2005 [Page 12]
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple