SHARE
TWEET

Untitled

a guest Jan 20th, 2011 28 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. Typing notifications for IRC
  2. Elizabeth J. Myers
  3. 20 Jan 2011
  4.  
  5.  
  6.  
  7. 1) Background
  8.  
  9. Many IM service provide a functionality where typing in the message box sends a
  10. notification to the other client that you are typing a message. This feature
  11. may be considered desirable to many users.
  12.  
  13. Various IM protocols do have problems with stale notifications or notifications
  14. being unreliable. We aim to avoid these pitfalls in our implementation. The
  15. goals for IRC typing notifications are as follows:
  16.  
  17.   1) Make it easy to integrate into clients via scripts.
  18.   2) Make the notifications optional.
  19.   3) Ensure notifications aren't too resource or bandwidth intensive.
  20.  
  21.  
  22.  
  23. 2) Negotiating support
  24.  
  25. Support of typing notifications is negotiated via the CAP extension, using the
  26. type-notify capability. See the CAP specification for more information
  27. regarding the implementation of such. Typing notifications remain in effect for
  28. the duration of the IRC session.
  29.  
  30. Some users may only want typing notifications for users. To support these users
  31. and to avoid wasting resources, users must explicitly state which notifications
  32. they wish to recieve via the TYPENOTIFY message as follows:
  33.  
  34. TYPENOTIFY [1|2|3]
  35.  
  36. TYPENOTIFY 1 specifies users-only. TYPENOTIFY 2 specifies channels-only (this
  37. is not likely to be used, but is implemented for the sake of completeness).
  38. TYPENOTIFY 3 specifies that the user wishes to recieve notifications for both
  39. channels and users. Users shall not issue a TYPENOTIFY message after they have
  40. already issued one. Additionally, no notifications shall be sent until the user
  41. issues a well-formed TYPENOTIFY message.
  42.  
  43.  
  44.  
  45. 3) Notifications
  46.  
  47. The actual notifications are pushed to the client via the ISTYPING, ENDTYPING,
  48. and PAUSETYPING statements. The format is similar to PRIVMSG:
  49.  
  50. :user!ident@host ISTYPING [channel|user]
  51. :user!ident@host PAUSETYPING [channel|user]
  52. :user!ident@host ENDTYPING [channel|user]
  53.  
  54.  
  55. ISTYPING
  56.  
  57. When a user is typing, they may issue an ISTYPING command to the directed
  58. channel or user. ISTYPING messages which are issued within too rapid of
  59. succession of each other should be silently ignored by the server (usually only
  60. one message per three seconds, but this is left undefined; sane values are
  61. recommended to avoid excessive bandwidth and resource consumption). ISTYPING
  62. messages sent to a channel that already has the user marked as typing shall be
  63. silently ignored.
  64.  
  65. Upon a channel join, if the user havs TYPENOTIFY 2 or 3, they shall be sent a
  66. "burst" of all pending typing notifications.
  67.  
  68.  
  69. PAUSETYPING
  70.  
  71. When the user has paused typing, they may send a PAUSETYPING message to the
  72. channel or user. Note that this command shall have no effect on the internal
  73. state of the typing status; is to be merely forwarded and possibly tracked.
  74. Servers which do not have the client marked as currently typing shall silently
  75. drop the message.
  76.  
  77. This command should be flood tracked in a similar manner to ISTYPING.
  78.  
  79.  
  80. ENDTYPING
  81.  
  82. When a user has deleted all the content of their text input box, they may issue
  83. an ENDTYPING message to signal they are not typing anymore. Note that an
  84. ENDTYPING message shall be silently ignored if the user has not previously
  85. issued an ISTYPING message to the given target.
  86.  
  87. After five minutes of an ISTYPING message being sent and no notification of the
  88. end of typing (PRIVMSG, QUIT, PART, etc.), the user's ISTYPING stauts should be
  89. cleared and an ENDTYPING notice is sent by the server to the target channel.
  90. This is to avoid a client having a lot of stale ISTYPING notifications lying
  91. around.
  92.  
  93.  
  94.  
  95. 3) Clearing notifications
  96.  
  97. Servers and clients shall clear the typing status of a user when one of these
  98. conditions are met:
  99.  
  100.   1) The user has issued a PRIVMSG to the target
  101.   2) The user or target has QUIT
  102.   3) The user has PART (applicable to channels only)
  103.   4) An ENDTYPING message has been recieved from the user
  104.   5) The user has been muted
  105.  
  106.  
  107.  
  108. 4) Tracking typing status
  109.  
  110. Servers and clients shall track the status based on the recieving of ISTYPING
  111. and ENDTYPING messages, provided they fulfil the conditions above. The typing
  112. status of a user shall be tracked based on channel. Typing statuses between
  113. users should not be tracked; there is little reason to, and it could be a
  114. potential resource hog. ISTYPING notices may be tracked, however, for the
  115. purposes of spam or flooding checking.
  116.  
  117. Servers shall only track notifications that are considered valid; invalid
  118. notifications shall not be acted on.
  119.  
  120.  
  121.  
  122. 5) Avoiding floods
  123.  
  124. Typing notifications should filtered the same way channel PRIVMSG's are with
  125. regards to flood control and such. For the purposes of flood control, an
  126. ISTYPING or PAUSETYPING  message should be considered the same as a PRIVMSG or
  127. a NOTICE. However, ENDTYPING messages shall not be flood tracked; users cannot
  128. send ENDTYPING messages to a channel without an ISTYPING message, and doing so
  129. could cause clients to have a lot of stale typing statues lying around.
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
Top