Subject: [Simple] Re: Comments on isComposing

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 09 May 2004 23:17:33 -0400

Responses to earlier comments, inline.

[email-masked] wrote:

> - The title mesions that this is for IM using SIP. Is this true?
> Can't this be used with any other IM protocol, including MSRP? I
> suggest removing SIP from the title and also changing the mime type
> to application/im-iscomposing+xml and the XML namespace to
> im-iscomposing

I'd be happy to do this. I vaguely recall some 'tactical' advice early 
on that advised against making broad claims, to avoid being seen as 
stepping on IMPP's turf. However, since IMPP is apparently dormant and 
hasn't seen a mailing list discussion since about one year ago, this 
consideration may no longer be operative. I'll happily change it 
according to your suggestion.

> 
> Description ------------
> 
> - "The composing user MAY specify a time-out interval measured in
> seconds, using the <timeout> element, after which the isComposing
> message is resent to refresh the state.  The refresh period SHOULD be
> no shorter than 60 seconds"
> 
> . Should this text be normative? It probably is, but then some text
> is needed describing the behaviour when this SHOULD is violated. I.e.
> What should the recipient do if it receives a refresh after less than
> 60 seconds? Some text needs to be added describing what the recipient

I don't see why the recipient needs to (or can) do anything. This is the 
not unusual - lots of protocols indicate minimum intervals, but 
receivers have to silently put up with over-eager senders (or use 
out-of-band mechanisms to complain to the implementor).

> does when a state times out. Does the recipient assume that the
> originator is instate idle? If so, then should the time-out be
> limited to active state (if a result of time out means that the
> originator is now idle, then there is no point of timing out on
> idle)?

Yes, since idle is the default state. I reworded the section a bit to 
make the timeouts clearer.

> 
> - "When the user starts composing again while in Idle state, the
> state transitions to Active, with the corresponding message."
> 
> What does "with the corresponding message" mean? Are you saying the a
> corresponding status message is sent? If so, please clarify.

Yes; clarified.

> 
> - "The idle timeout SHOULD be ten seconds." I agree this is normative
> text, but some more text needs to be added describing the
> consequences of the originator not sending an idle state message.
> I.e. The recipient would have false info that the originator is now
> composing when he is not.

Until the timeout interval, yes. Hopefully, the timeout rewording will 
make this clearer.

> 
> - "If an instant message is sent before the idle threshold expires,
> no idle state indication is needed"
> 
> Should some text be added stating that the idle timer is
> started/reset when composing a message ends and the message has been
> sent, and is disabled when composing a message begins?

The whole mechanism starts with the first typing and ends with the 
message being sent (or abandoned), so there isn't really a timer to reset.

> 
> . Should the sentence continue to state that "The recipient should,
> after receiving the instant message, assume the sender is now in idle
> state"?

Yes. That's the default state.

> 
> - "Thus, in most cases, only one message is needed.  The message rate
> is limited to one message per idle threshold interval."
> 
> Is this talking about a status message? If so, please indicate so. If
> not, then the question is why is there a limit to how many messages
> per idle threshold is specified? Please clarify this sentence.

Reworded.

> 
> - "The isComposing indicator MAY be carried in CPIM messages 
> [I-D.ietf-impp-cpim-msgfmt]."
> 
> Why is this method of carrying the isComposing indicator singled out
> and mentioned here when all other possibilities are not mentioned?

Just because it's the most common one? I can drop this, but it seems 
harmless.

> 
> Using the Indicator ---------------------
> 
> - " First, it ensures proper sequencing and synchronization with the
> actual messages being composed"
> 
> Can some more text or flows be added to emphasise the point more?

Added.

> 
> Security Considerations ------------------------
> 
> You might want to mention that since the status messages are carried
> using the IM protocol itself, all security protection mechanisms for
> that IM protocol apply wen also carrying the status in a message.

Noted.

> Thanks, Hisham

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 09 May 2004 23:17:33 -0400

Yes; clarified.

Reworded.

Added.

Noted.