On Wed, 18 Jul 2018 20:40:45 +0500 Ненахов Андрей <andrew.nenak...@redsolution.ru> wrote: > I'd rather call it 'extended chat state notifications' or something > like that. Recording audio is only distantly related to file sharing.
I can see your point, but I don't think that the name 'Extended Chat State Notifications' describes the XEP better. On Thu, 19 Jul 2018 15:48:42 +0200 Jonas Wielicki <jo...@wielicki.name> wrote: > 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 :). Ah ok, I understand that better now. :) > 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.) Makes sense. +1 > In the Business Rules I think you meant "When sending a <creating/> > or <uploading/> notification […]" (instead of ``composing``)). Yeah, will fix that. > 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. I somehow thought of <paused/> as stopped writing instead of actually pausing. Then going back to <active/> <inactive/> makes more sense of course. > I think this section can use some structural improvement. How’s this? > (I also changed the rules a bit, see below): > [...] I think that's easier to understand. > - 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?) I think using something as 'in the last 10 seconds' makes the implementations much more complicated. Another option would be to just send no <composing/> at all as it is currently. I agree with you on the other points. Regards, Linus _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________