1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
|
<pre>Network Working Group H. Schulzrinne
Request for Comments: 3994 Columbia U.
Category: Standards Track January 2005
<span class="h1">Indication of Message Composition for Instant Messaging</span>
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.
<span class="grey">Schulzrinne Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3994">RFC 3994</a> isComposing January 2005</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology and Conventions . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Description . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Overview . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. Message Composer Behavior . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.3">3.3</a>. Status Message Receiver Behavior . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.4">3.4</a>. Message Content . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.5">3.5</a>. Additional Status Information . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4">4</a>. Using the Status Message . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5">5</a>. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6">6</a>. XML Document Format . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6.1">6.1</a>. XML Schema . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-7">7</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-8">8</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
8.1. Content-Type Registration for
'application/im-iscomposing+xml' . . . . . . . . . . . . <a href="#page-10">10</a>
8.2. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:im-iscomposing' . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8.3">8.3</a>. Schema Registration . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-9">9</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-10.2">10.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
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 <a href="#section-3">Section 3</a> 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
<span class="grey">Schulzrinne Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3994">RFC 3994</a> isComposing January 2005</span>
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 <a href="#section-6">Section 6</a>, 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 [<a href="#ref-6" title=""Presence Information Data Format (PIDF)"">6</a>], 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 [<a href="#ref-7" title=""Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP)"">7</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology and Conventions</span>
This memo makes use of the vocabulary defined in the IMPP Model
document [<a href="#ref-1" title=""A Model for Presence and Instant Messaging"">1</a>]. 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 <a href="https://www.rfc-editor.org/bcp/bcp14">BCP</a>
<a href="https://www.rfc-editor.org/bcp/bcp14">14</a>, <a href="./rfc2119">RFC 2119</a> [<a href="#ref-2" title=""Key words for use in RFCs to Indicate Requirement Levels"">2</a>].
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.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Description</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Overview</span>
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.
<span class="grey">Schulzrinne Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3994">RFC 3994</a> isComposing January 2005</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Message Composer Behavior</span>
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 <state> 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
<refresh> 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.
<span class="grey">Schulzrinne Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3994">RFC 3994</a> isComposing January 2005</span>
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
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Status Message Receiver Behavior</span>
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 <refresh> 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.
<span class="grey">Schulzrinne Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3994">RFC 3994</a> isComposing January 2005</span>
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
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Message Content</span>
We briefly describe the message content to summarize the discussion
above. This description is non-normative. The schema (<a href="#section-6">Section 6</a>)
should be consulted for the normative message format.
The message consists of an <isComposing> element, with a mandatory
<state> element indicating the composer state; i.e., idle or active.
In addition, there are three optional elements: <lastactive>,
indicating the time of last activity; <contenttype>, the type of
message being created; and <refresh>, the time interval after which
the receiver can expect an update from the composer. Details are
given in the following section.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Additional Status Information</span>
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.
<span class="grey">Schulzrinne Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3994">RFC 3994</a> isComposing January 2005</span>
The optional <lastactive> element describes the absolute time when
the user last added or edited content.
The optional <contenttype> 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 [<a href="#ref-3" title=""Common Presence and Instant Messaging (CPIM): Message Format"">3</a>].
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.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Using the Status Message</span>
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.
<span class="grey">Schulzrinne Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3994">RFC 3994</a> isComposing January 2005</span>
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.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Examples</span>
<?xml version="1.0" encoding="UTF-8"?>
<isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:im-composing
iscomposing.xsd">
<state>active</state>
<contenttype>text/plain</contenttype>
<refresh>90</refresh>
</isComposing>
<?xml version="1.0" encoding="UTF-8"?>
<isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:im-composing
iscomposing.xsd">
<state>idle</state>
<lastactive>2003-01-27T10:43:00Z</lastactive>
<contenttype>audio</contenttype>
</isComposing>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. XML Document Format</span>
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
<span class="grey">Schulzrinne Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3994">RFC 3994</a> isComposing January 2005</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. XML Schema</span>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:im-iscomposing"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:im-iscomposing">
<xs:element name="isComposing">
<xs:complexType>
<xs:sequence>
<xs:element name="state" type="xs:string"/>
<xs:element name="lastactive" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="contenttype" type="xs:string"
minOccurs="0"/>
<xs:element name="refresh" type="xs:positiveInteger"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
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.
<span class="grey">Schulzrinne Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3994">RFC 3994</a> isComposing January 2005</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Content-Type Registration for 'application/im-iscomposing+xml'</span>
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 <a href="./rfc3023">RFC 3023</a> [<a href="#ref-4" title=""XML Media Types"">4</a>],
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: <a href="./rfc3994">RFC 3994</a>
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 <a href="./rfc3023">RFC 3023</a> [<a href="#ref-4" title=""XML Media Types"">4</a>], and many of the considerations
described there also apply to application/im-iscomposing+xml.
<span class="grey">Schulzrinne Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3994">RFC 3994</a> isComposing January 2005</span>
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. URN Sub-Namespace Registration for</span>
'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
<a href="./rfc3994">RFC 3994</a> 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
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"<a href="http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd</a>">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Is-composing Indication for Instant Messaging</title>
</head>
<body>
<h1>Namespace for SIMPLE iscomposing extension</h1>
<h2>urn:ietf:params:xml:ns:im-composing</h2>
<p>See <a href="[URL of published RFC]"><a href="./rfc3994">RFC3994</a></a>.</p>
</body>
</html>
END
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. Schema Registration</span>
This section registers a new XML schema per the procedures in [<a href="#ref-5" title=""The IETF XML Registry"">5</a>].
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 <a href="#section-6.1">Section</a>
<a href="#section-6.1">6.1</a>.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span>
Ben Campbell, Miguel Garcia, Scott Hollenbeck, Christian Jansson,
Cullen Jennings, Hisham Khartabil, Allison Mankin, Aki Niemi,
Jonathan Rosenberg, and Xiaotao Wu provided helpful comments.
<span class="grey">Schulzrinne Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3994">RFC 3994</a> isComposing January 2005</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
Instant Messaging", <a href="./rfc2778">RFC 2778</a>, February 2000.
[<a id="ref-2">2</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-3">3</a>] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
(CPIM): Message Format", <a href="./rfc3862">RFC 3862</a>, August 2004.
[<a id="ref-4">4</a>] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", <a href="./rfc3023">RFC</a>
<a href="./rfc3023">3023</a>, January 2001.
[<a id="ref-5">5</a>] Mealling, M., "The IETF XML Registry", <a href="https://www.rfc-editor.org/bcp/bcp81">BCP 81</a>, <a href="./rfc3688">RFC 3688</a>, January
2004.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-6">6</a>] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)", <a href="./rfc3863">RFC</a>
<a href="./rfc3863">3863</a>, August 2004.
[<a id="ref-7">7</a>] 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: <a href="http://www.cs.columbia.edu/~hgs">http://www.cs.columbia.edu/~hgs</a>
<span class="grey">Schulzrinne Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3994">RFC 3994</a> isComposing January 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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.
Schulzrinne Standards Track [Page 13]
</pre>
|
