Added Requirements and Acknowledgements, simplified some definitions and added rules for CSI.
The specification of &xep0085; defines a protocol for exchanging information about the activity of the user, for example that the user is currently typing. However with the new possibilities of media sharing as in &xep0385; and &xep0363; there are also new desirable chat states. For example when a user uploads an image, the upload usually takes a while. To notify the chat partner about the uploading process a new chat state is required.
-When users send large files or have a very slow upstream connection it can make the chat partner confused when they are receiving a sending state for a long time. In these cases it can be nice to give the chat partner information about the upload progress. This way the chat partner can estimate if a file will arrive immediately or if it is better to go and get a coffee first.
-Apart from notifications for sending files, there should also be notifications when a user is creating new media files, for example when the user is recording audio, a video or is taking a picture.
+When users send large files or have a very slow upstream connection it can make the chat partner confused when they are receiving an uploading state for a long time. In these cases it can be nice to share the upload progress. This way the chat partner can estimate if a file will arrive immediately or if it is better to go and get a coffee first.
+Apart from notifications for sending files, there should also be notifications when a user is creating new media files, for example when the user is recording audio, recording a video or is taking a picture.
+Bernardo is informing Francisco about his activity of taking a picture to send it afterwards. If Francisco's client supports file sharing notifications, it should display this as something similiar as 'Bernardo is taking a photo...'.
-A list of possible 'types' can be found below.
-| Type | Definition | ||
|---|---|---|---|
| photo | -User is taking a picture. | +animation | +An animated image file, for example a GIF file. It SHOULD NOT be used in the <creating/> state. | +
| audio | +An audio file. This MAY also be displayed as a voice recording when used in the <creating/> state. | +||
| image | +An image file. | ||
| video | -User is recording a video. | -||
| voice | -User is recording their voice. | +A video file. |
Bernardo has taken a good picture for sending and has started uploading, now. The same notification is also used when the image existed before and there were no process of creating it.
The 'progress' attribute has to be in the range of zero (0) and one (1). With other words the bytes sent divided by the total bytes. Generally the progress SHOULD NOT have more than two digits after the decimal point since the exact uploading status isn't important. Also there SHOULD be no more progress updates than once per second.
-A table of possible 'types' is listed below.
-| Type | -Definition | -
|---|---|
| animation | -An animated image file, for example a GIF file. | -
| audio | -An audio file. | -
| image | -An image file. | -
| video | -A video file. | -
The 'type' attribute equals the 'type' attribute by the <creating/> element.
If the client also supports &xep0085;, then it SHOULD also send chat states for backwards-compatibility. In this case clients without support file sharing notifications, still receive a normal <composing/> state.
-When sending a <composing/> or <uploading/> notification, the client SHOULD send a <composing/> state, but only as long as the user is active. When the <upload-aborted/> notification is sent the <paused/> state MUST be used.
-Of course the <composing/> state has to be cleared on completion of a file upload and the <active/> state SHALL be sent.
-It is allowed to send a file sharing notification even if according to &xep0085; the user is <inactive/>, for example when the client is continuing a file upload, while the user is doing something else. But keep in mind that the chat state MUST go back to <composing/> when the user becomes active again and the upload is still running. Also, the user SHOULD NOT be seen as <inactive/> while selecting a file or using another application to take a photo, record voice or record a video.
+When a sending client chooses to map file sharing notifcations to &xep0085;, it MUST follow the following rules:
+A client MAY choose not to apply this mapping if it allows text input while creating or uploading media, to allow transmitting normal XEP-0085 states for the text input.
+If a client allows a user to pick media which are already created (thus skipping the <creating/> state), it MAY treat interaction with the media selection like text input in XEP-0085 (i.e. send <composing/> while the user is actively engaging with it and switch to <paused/> if inactive for a certain time).
Media sharing protocols as &xep0385; don't forbid concurrent file uploads, so it may be the case that a client is uploading multiple files of different types to the same user or groupchat at the same time. This could result in different file types being affected at the same time. However, a client MUST NOT send multiple <uploading/> or <creating/> elements and it MUST NOT send a combination of those elements. In this case the client SHOULD send the state of the upload with the lowest file size.
+Media sharing protocols as &xep0385; don't forbid concurrent file uploads, so it may be the case that a client is uploading multiple files of different types to the same user or groupchat at the same time. This could result in different file types being affected at the same time. + In this case clients SHOULD follow these rules:
+Servers supporting &xep0352; SHOULD discard messages containing only a file sharing notification as long as a client is inactive.
+File sharing notifications MAY be used in groupchats as defined in &xep0045; or &xep0369; just as in normal chats.
tbd
Thanks to Jonas Wielicki for his helpful feedback and input.
+