Subject: [Simple] New WG charter topic: draft-aoki-feel-00.txt ?

From: "Orit Levin" <[email-masked]>
Date: Fri, 1 Apr 2005 16:29:00 -0800

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.
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Apr 2005 21:50:10 -0500

Orit,

I think most folks would agree that this is a problem. However, I am not 
sure I agree with the solution.

When this has come up in the past, the general answer has been to use 
richer IM formats, such as html, that allow inclusion of graphical 
elements that convey the actual emoticon. This eliminates all of the 
interoperability issues you mention, and requires no additional 
standards work. Your draft doesnt discuss this option, and I am curious 
whether you considered it and rejected it, or had not considered it.

I can think of only a few reasons why an embedded graphic would be a 
problem:

1. message size constraints, though the emoticon images are tiny and 
this seems not really a big deal

2. because there is a desire to translate the emoticon, and thus 
something that can be interpreted by an automata is required.

Your draft touches on the second point. However, I'm not sure that 
translation is what is really desired. I think most users would be 
surprised and confused if they think they sent an image of a user 
chugging a beer, and then the recipient got a user sipping wine. How can 
the originating UA figure out the user INTENT when they selected the 
"chugging beer" emoticon? Your draft assumes that the user meant "having 
a drink". What if the intent of the communications was explicitly around 
beer, and NOT some other type of beverage?

Thanks,
Jonathan R.

Orit Levin wrote:

> ------------------------------------------------------------------------
> 
> 
> 
> 
> 
> 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: [email-masked]
> 
> 
>    Orit Levin
>    Microsoft Corporation
>    One Microsoft Way
>    Redmond, WA  98052
>    USA
> 
>    Email: [email-masked]
> 
> 
>    Tim Rang
>    Microsoft Corporation
>    One Microsoft Way
>    Redmond, WA  98052
>    USA
> 
>    Email: [email-masked]
> 
> 
> 
> 
> 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: [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 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
>    [email-masked].
> 
> 
> 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]
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Apr 2005 22:12:40 -0500

I wasn't quite sure whether this was a draft that needed a morality 
considerations section according to RFC 4041.

In any event, from a minute of googling, there have been earlier 
attempts at related things:

See http://www.vhml.org/vhml_about/html/vhml_about.shtml
http://www.humanmarkup.org

Jabber apparently allows moods in messages, too: 
http://www.jabber.org/jeps/jep-0107.html

None of the emotional markup languages seem to have made much progress.

---

From: Edwin Aoki <[email-masked]>
Date: Fri, 01 Apr 2005 19:26:51 -0800

Jonathan, Henning,

All very good points, but the other issue with emoticon images comes 
from translation across different device boundaries.  For example, a 
mobile phone terminal might not have the ability to display an emoticon 
image, or the message might traverse a text-to-speech agent on the way 
to a black phone.  In this case, certain translations are going to be 
required, and you'd want the semantics of that to be well-defined.

We'll definitely look into the morality considerations concern, 
particularly in response to sending the "chugging a beer" emoticon to 
underage recipients.  That was something we'd completely overlooked.

Thanks,
-Edwin

[email-masked] wrote:

> Orit,
>
> I think most folks would agree that this is a problem. However, I am 
> not sure I agree with the solution.
>
> standards work. Your draft doesnt discuss this option, and I am 
> curious whether you considered it and rejected it, or had not 
> considered it.
>
> chugging a beer, and then the recipient got a user sipping wine. How 
> can the originating UA figure out the user INTENT when they selected 
> the "chugging beer" emoticon? Your draft assumes that the user meant 
> "having a drink". What if the intent of the communications was 
> explicitly around beer, and NOT some other type of beverage?
>
> Thanks,
> Jonathan R.
>
> Orit Levin wrote:
>
>>  
>> Guys,
>>
>>    |                      | or sport             
>> |                       |
>>    |          |               |              |           | or 
>> angry      |
>>    |          |               |              |           | Sad, 
>> Confused |
>>    |          |               |              |           | 
>> beverage      |
>>    | (D)      | Having a      |              |           
>> |               |