分享
 
 
 

RFC3994-Indication of Message Composition for Instant Messaging

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group H. Schulzrinne

Request for Comments: 3994 Columbia U.

Category: Standards Track January 2005

Indication of Message Composition for Instant Messaging

Status of This Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2005).

Abstract

In instant messaging (IM) systems, it is useful to know during an IM

conversation whether the other party is composing a message; e.g.,

typing or recording an audio message. This document defines a new

status message content type and XML namespace that conveys

information about a message being composed. The status message can

indicate the composition of a message of any type, including text,

voice, or video. The status messages are delivered to the instant

messaging recipient in the same manner as the instant messages

themselves.

Table of Contents

1. IntrodUCtion . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3

3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3

3.2. Message Composer Behavior . . . . . . . . . . . . . . . 4

3.3. Status Message Receiver Behavior . . . . . . . . . . . . 5

3.4. Message Content . . . . . . . . . . . . . . . . . . . . 6

3.5. Additional Status Information . . . . . . . . . . . . . 6

4. Using the Status Message . . . . . . . . . . . . . . . . . . . 7

5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

6. XML Document Format . . . . . . . . . . . . . . . . . . . . . 8

6.1. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 9

7. Security Considerations . . . . . . . . . . . . . . . . . . . 9

8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10

8.1. Content-Type Registration for

'application/im-iscomposing+xml' . . . . . . . . . . . . 10

8.2. URN Sub-Namespace Registration for

'urn:ietf:params:xml:ns:im-iscomposing' . . . . . . . . 11

8.3. Schema Registration . . . . . . . . . . . . . . . . . . 11

9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11

10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12

10.1. Normative References . . . . . . . . . . . . . . . . . . 12

10.2. Informative References . . . . . . . . . . . . . . . . . 12

Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12

Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13

1. Introduction

By definition, instant messaging (IM) is message based: A user

composes a message by, for example, typing, speaking, or recording a

video clip. This message is then sent to one or more recipients.

Unlike email, instant messaging is often conversational, so the other

party is waiting for a response. If no response is forthcoming, a

participant in an instant messaging conversation may erroneously

assume either that the communication partner has left or that it is

her turn to type again, leading to two messages "crossing on the

wire".

To avoid this uncertainty, a number of commercial instant messaging

systems feature an "is-typing" indication sent as soon as one party

starts typing a message. In this document, we describe a generalized

version of this indication, called the isComposing status message.

As described in Section 3 in more detail, a status message is

delivered to the instant message recipient in the same manner as are

the messages themselves. The isComposing status messages can

announce the composition of any media type, not just text. For

example, it might be used if somebody is recording an audio or video

clip. In addition, it can be extended to convey other instant

messaging user states in the future. Below, we will call these

messages "status messages" for brevity.

The status messages are carried as XML, as instances of the XML

schema defined in Section 6, and labeled as an

application/im-iscomposing+xml content type.

These status messages can be considered somewhat analogous to the

comfort noise packets that are transmitted in silence-suppressed

interactive voice conversations.

Events and extensions to presence, such as PIDF [6], were also

considered but have a number of disadvantages. They add more

overhead, as an eXPlicit and periodic subscription is required.

For page-mode delivery, subscribing to the right user agent and

set of messages may not be easy. An in-band, message-based

mechanism is also easier to translate across heterogeneous instant

messaging systems.

The mechanism described here aims to satisfy the requirements in [7].

2. Terminology and Conventions

This memo makes use of the vocabulary defined in the IMPP Model

document [1]. In this memo, terms such as CLOSED, INSTANT MESSAGE,

OPEN, PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT

are used with the same meaning defined therein. The key Words MUST,

MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and

OPTIONAL in this document are to be interpreted as described in BCP

14, RFC 2119 [2].

This document discusses two kinds of messages; namely, the instant

message (IM) conveying actual content between two or more users

engaged in an instant messaging conversation, and the status message,

described in this document, which indicates the current composing

status to the other participants in a conversation. We use the terms

"content message" and "status message" for these two message types.

3. Description

3.1. Overview

We model the user of an instant messaging system as being in one of

several states, in this document limited to "idle" and "active". By

default, the user is in "idle" state, both before starting to compose

a message and after sending it.

3.2. Message Composer Behavior

Only the instant messaging user agent actively composing a content

message generates status messages indicating the current state. When

the user starts composing a content message (the actual instant

message), the state becomes "active", and an isComposing status

message containing a element indicating "active" is sent to

the recipient of the content message being composed. As long as the

user continues to produce instant message content, the user remains

in state "active".

There are two sender timers: the active-state refresh interval, and

the idle time-out interval.

The active-state refresh interval determines how often "active" state

messages are sent while the composer remains in "active" state. The

interval is chosen by the composing user and indicated in the

element in the status message, expressed in integer

seconds. Each transmission of the isComposing message resets the

timer. The interval SHOULD be no shorter than 60 seconds. A message

composer MAY decide not to send active-state refresh messages at all.

This is indicated by omitting the refresh interval; this will cause

the receiver to assume that it has gone idle after 120 seconds. (In

most cases, the content message will have been sent by then.) No

refresh messages are sent in "idle" state.

The active-state refresh mechanism deals with the case in which

the user logs off or the application crashes before the content

message is completed.

If the user stops composing for more than a configured time interval,

the idle timeout, the state transitions to "idle", and an "idle"

status message is sent. If the user starts composing again while in

"idle" state, the state transitions to "active", and the

corresponding status message is sent. Unless otherwise configured by

the user, the idle timeout SHOULD have a default value of 15 seconds.

If a content message is sent before the idle threshold expires, no

"idle" state indication is needed. Thus, in most cases, only one

status message is generated for each content message. In any event,

the message rate is limited to one status message per refresh

threshold interval.

The state transitions are shown in Figure 1.

+-------------+

+-----------+

+------> idle <--------+

+-----------+

+------+------+

content idle timeout

msg. sent composing w/o activity

----------- ------------- ------------------

-- "active" msg. "idle" status msg.

+------V------+

+------+ active +--------+

------+

+------^------+ refresh timeout

--------------------

"active" status msg.

+-------------+

Figure 1. Sender State Diagram

3.3. Status Message Receiver Behavior

The status message receiver uses the status messages to determine the

state of the content message sender. If the most recent "active"

status message contained a value, the refresh time-out is

set to that value; otherwise, it is 120 seconds. The state at the

receiver transitions from "active" to "idle" under three conditions:

1. A status message with status "idle" is received.

2. A content message is received.

3. The refresh interval expires.

Receivers MUST be able to handle multiple consecutive isComposing

messages with "active" state, regardless of the refresh interval.

The state transitions are shown in Figure 2.

+-------------+

+-----------+

+------> idle <------+

+-----------+

+------+------+

"idle" recd. "active" msg. refresh timeout

or content recd. or 120s

+------V------+

+------+ active +------+

+-------------+

Figure 2. Receiver State Diagram

3.4. Message Content

We briefly describe the message content to summarize the discussion

above. This description is non-normative. The schema (Section 6)

should be consulted for the normative message format.

The message consists of an element, with a mandatory

element indicating the composer state; i.e., idle or active.

In addition, there are three optional elements: ,

indicating the time of last activity; , the type of

message being created; and , the time interval after which

the receiver can expect an update from the composer. Details are

given in the following section.

3.5. Additional Status Information

The status message contains additional optional elements to provide

further details on the composition activity. Any of these can appear

in both "active" and "idle" state messages.

The optional element describes the absolute time when

the user last added or edited content.

The optional element indicates the type of medium in

which the messaging terminal is currently composing. It can contain

either just a MIME media type, such as "audio" or "text", or a media

type and suBType, such as "text/Html". It is best understood as a

hint to the user, not a guarantee, that the actual content message

will indeed contain only the content indicated. It allows the human

recipient to be prepared for the likely message format.

To further describe message composition, the XML schema or the set of

allowable state names can be extended in future documents.

Recipients of status messages implementing this specification without

extensions MUST treat state tokens other than "idle" and "active" as

"idle". Additional elements MUST use their own namespaces and MUST

be designed so that receivers can safely ignore such extensions.

Adding elements to the namespace defined in this document is not

permitted.

The isComposing status message MAY be carried in CPIM messages [3].

Such a wrapper is particularly useful if messages are relayed by a

conference server since the CPIM message maintains the identity of

the original composer.

4. Using the Status Message

The isComposing status message can be used with either page mode or

session mode, although session mode is a more natural fit. In

session mode, the status message is sent as part of the messaging

stream. Its usage is negotiated just like any other media type in

that stream, with details depending on the session mode protocol.

Sending the status messages within the session-mode messaging stream

has at least three benefits. First, it ensures proper ordering and

synchronization with the actual content messages being composed. In

messaging systems that guarantee in-order delivery of messages, this

approach avoids having an active indication appear at the receiver

after the actual message has been delivered, due to message

reordering across two delivery mechanisms.

Secondly, end-to-end security can be applied to the messages.

Thirdly, session negotiation mechanisms can be used to turn it on and

off at any time, and even to negotiate its use in a single direction

at a time.

Usage with page mode is also straightforward: The status message is

carried as the body of a page mode message. In SIP-based IM, The

composer MUST cease transmitting status messages if the receiver

returned a 415 status code (Unsupported Media Type) in response to a

MESSAGE request containing the status indication.

The sender cannot be assured that the status message is delivered

before the actual content being composed arrives. However, SIP page

mode is limited to one unacknowledged message, so out-of-order

delivery is unlikely, albeit still possible if proxies are involved.

5. Examples

active

text/plain

90

idle

2003-01-27T10:43:00Z

audio

6. XML Document Format

An isComposing document is an XML document that MUST be well formed

and SHOULD be valid. isComposing documents MUST be based on XML 1.0

and MUST be encoded by using UTF-8. This specification makes use of

XML namespaces for identifying isComposing documents. The namespace

URI for elements defined for this purpose is a URN using the

namespace identifier 'ietf'. This URN is:

urn:ietf:params:xml:ns:im-iscomposing

6.1. XML Schema

7. Security Considerations

The isComposing indication provides a fine-grained view of the

activity of the entity composing and thus deserves particularly

careful confidentiality protection so that only the intended

recipient of the message will receive the isComposing indication.

Since the status messages are carried by using the IM protocol

itself, all security considerations of the underlying IM protocol

also apply to the isComposing status messages.

There are potential privacy issues in sending isComposing status

messages before an actual conversation has been established between

the communicating users. A status message may be sent even if the

user later abandons the message. It is RECOMMENDED that isComposing

indications in page mode are only sent when a message is being

composed as a reply to an earlier message. This document does not

prescribe how an implementation detects whether a message is in

response to an earlier one in page mode, but elapsed time or user

interface behavior might be used as hints.

8. IANA Considerations

8.1. Content-Type Registration for 'application/im-iscomposing+xml'

To: ietf-types@iana.org

Subject: Registration of MIME media type application/

im-iscomposing+xml

MIME media type name: application

MIME subtype name: im-iscomposing+xml

Required parameters: (none)

Optional parameters: charset; Indicates the character encoding of

enclosed XML. Default is UTF-8.

Encoding considerations: Uses XML, which can employ 8-bit characters,

depending on the character encoding used. See RFC 3023 [4],

section 3.2.

Security considerations: This content type is designed to carry

information about current user activity, which may be considered

private information. Appropriate precautions should be adopted to

limit disclosure of this information.

Interoperability considerations: This content type provides a common

format for exchange of composition activity information.

Published specification: RFC 3994

Applications which use this media type: Instant messaging systems.

Additional information: none

Person & email address to contact for further information: Henning

Schulzrinne, hgs@cs.columbia.edu

Intended usage: LIMITED USE

Author/Change controller: This specification is a work item of the

IETF SIMPLE working group, with the mailing list address

simple@ietf.org.

Other information: This media type is a specialization of

application/xml RFC 3023 [4], and many of the considerations

described there also apply to application/im-iscomposing+xml.

8.2. URN Sub-Namespace Registration for

'urn:ietf:params:xml:ns:im-iscomposing'

URI: urn:ietf:params:xml:ns:im-iscomposing

Description: This is the XML namespace for XML elements defined by

RFC 3994 to describe composition activity by an instant messaging

client using the application/im-iscomposing+xml content type.

Registrant Contact: IETF, SIMPLE working group, simple@ietf.org,

Henning Schulzrinne, hgs@cs.columbia.edu

XML:

BEGIN

Namespace for SIMPLE iscomposing extension

urn:ietf:params:xml:ns:im-composing

See RFC3994.

END

8.3. Schema Registration

This section registers a new XML schema per the procedures in [5].

URI: urn:ietf:params:xml:schema:im-composing

Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),

Henning Schulzrinne (hgs@cs.columbia.edu).

The XML for this schema can be found as the sole content of Section

6.1.

9. Acknowledgements

Ben Campbell, Miguel Garcia, Scott Hollenbeck, Christian Jansson,

Cullen Jennings, Hisham Khartabil, Allison Mankin, Aki Niemi,

Jonathan Rosenberg, and Xiaotao Wu provided helpful comments.

10. References

10.1. Normative References

[1] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and

Instant Messaging", RFC 2778, February 2000.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement

Levels", BCP 14, RFC 2119, March 1997.

[3] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging

(CPIM): Message Format", RFC 3862, August 2004.

[4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC

3023, January 2001.

[5] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January

2004.

10.2. Informative References

[6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and

J. Peterson, "Presence Information Data Format (PIDF)", RFC

3863, August 2004.

[7] Rosenberg, J., "Advanced Instant Messaging Requirements for the

Session Initiation Protocol (SIP)", Work in Progress, February

2004.

Author's Address

Henning Schulzrinne

Columbia University

Department of Computer Science

450 Computer Science Building

New York, NY 10027

US

Phone: +1 212 939 7004

EMail: hgs@cs.columbia.edu

URI: http://www.cs.columbia.edu/~hgs

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

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.

Intellectual Property

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 IETF's procedures with respect to rights in IETF 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@ietf.org.

Acknowledgement

Funding for the RFC Editor function is currently provided by the

Internet Society.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有