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 similarly to 'Bernardo is taking a photo…'.

A list of possible 'type' attributes is defined below.

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 client SHOULD include a 'progress' attribute. It MUST be in the range of zero (0) and one (1). This value represents the bytes already sent divided by the total bytes. Generally it is not necessary to include more than two digits after the decimal point since the exact uploading status is not important. Clients MUST NOT send progress updates more often than once per second.

The 'type' attribute equals the 'type' attribute by the <creating/> element.

The file upload has succeeded. Now Bernardo can send the file sharing message as in &xep0385; or another file sharing protocol. Francisco's client MUST clear the previous <uploading> notification. The <upload-finished/> notification itself SHOULD NOT be displayed to the user.

Of course the file upload also could have ended otherwise. In this case Bernardo has manually aborted the file upload. If the client encounters problems with the upload service after sending the first file sharing notification, the same format will also be used.

When a sending client chooses to map file sharing notifcations to &xep0085;, it MUST follow the following rules:

• As long as no upload or creation is in progress, the normal XEP-0085 states are sent.
• During creation, a client MUST send <composing/> state (overriding the state which would normally be sent with XEP-0085 logic).
• During upload and while the user is active, a client SHOULD continue to send the <composing/> state (overriding the state which would normally be sent with XEP-0085 logic).
• During upload and while the user is inactive, a client SHOULD send <inactive/> instead of <composing/>.
• After the upload finishes or is aborted, the normal XEP-0085 logic takes over. Normally, this will put the conversation into <active/> or <inactive/> state (but if the user still has input pending, it may also be <paused/>).

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. In this case clients SHOULD follow these rules:

• Multiple <uploading/> or <creating/> elements or a combination of these MUST NOT be sent.
• <creating/> notifications SHOULD be preferred to <uploading/> notifications.
• If there are multiple running file uploads, a notification for the approximately next finishing upload SHOULD be sent.

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.

This specification defines the following XML namespace:

• urn:xmpp:fsn:0

Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.