On Donnerstag, 19. Juli 2018 15:28:20 CEST Jonas Wielicki wrote: > On Mittwoch, 18. Juli 2018 17:34:08 CEST Jonas Wielicki wrote: > > URL: https://xmpp.org/extensions/inbox/fsn.html
A few more remarks. I’d normally against giving non-critical feedback in ProtoXEP stage, but given that the Council is on vacation next week, it makes may sense to sort out the rough edges now. A requirements section is very much needed. "Requirements" is meant as in "What is required of the protocol?" and not as in "Dependencies". So here you’d probably have something like: > * Convey upload state > * Distinguish media types > * Convey recording state > * Signal cancelling of uploads > * Allow co-existence with XEP-0085 > * Define recommended rules for interop with XEP-0085 Just with fancier words :). Looking at the first table: I suggest to use the same definition of types for both uploading and recording. Animation may not make sense (and we can discourage use with SHOULD NOT) for recording, but having the same set of values for both seems better to me. Especially since an audio recording is not necessarily a voice recording (if a client chooses to present it if it was, that’s fine; it doesn’t need to be reflected on the protocol level.) In the Business Rules I think you meant "When sending a <creating/> or <uploading/> notification […]" (instead of ``composing``)). I’m also not sure forcing ``paused`` here makes sense. If the upload failed, the user may not be actively looking at the screen and thus a ``paused`` state may be confusing to the recipient. If the user aborted the upload, they may have decided to not share anything after all. In both cases, going back to ``active`` or ``inactive`` (whichever is true) seems more appropriate to me. Remove the "Of course" from the third paragraph and replace it with a MUST. I would suggest to not force <active/> state, because the user might not be actively engaged in the conversation or even with the device at the time the upload finishes. Use whatever XEP-0085 state is appropriate. I think this section can use some structural improvement. How’s this? (I also changed the rules a bit, see below): > When a sending client chooses to map FSNs to XEP-0085, 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). Changes: - Make it clear that after the upload is over, normal XEP-0085 rules take over (instead of forcing any XEP-0085 state). - Use MUST for creating and SHOULD for uploading; I think for uploading we’ll have to see how this actually looks and feels to users, especially with long uploads (maybe it would be nice to only show <composing/> in the last (approximately) 10 seconds of an upload?) - Add rules for clients which allow text input while uploading. - Add rules for states while picking a file. kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
