On 2 Jul 2013 18:47, "Mark Rejhon" <[email protected]> wrote: > >> >> 4.7.3 "The message refresh SHOULD be transmitted regularly at an >> average interval of 10 seconds during active typing or composing. This >> interval is frequent enough to minimize user waiting time, while being >> infrequent enough to not cause a significant bandwidth overhead. This >> interval MAY vary, or be set to a longer time period, in order to >> reduce average bandwidth (e.g. long messages, infrequent or minor >> message changes)." >> >> It feels to me like this is really saying "It is suggested that a >> message refresh be transmitted regularly at an..." - otherwise the >> SHOULD and the MAY seem contradictory. > > > The "SHOULD" refers to an exact 10 second interval. > The "MAY" refers to a varying time interval (not exactly 10 seconds). > I can remove the second "MAY" into a "suggested", but the first "SHOULD" is far more important as we've found it greatly improved reliability during the emergency-use/911 tests/work with InDigital's demo. I was considering changing it to a "MUST" (I had pressure for that). >
You're mixing two different levels of conformance. On the one hand, you've a fairly vague (IMHO) "SHOULD", then you immediately say MAY about the same thing. SHOULD means that if you don't do this, it might well cause interoperability problems. This doesn't seem to be the case, because implementations "MAY" - truly optionally - vary that interval as they see fit. Kev's text replaces the SHOULD with a normative-level-free "It is suggested", which is basically an implementation note. What you might want to do is say that the interval SHOULD be no more than X, and no less than Y; SHOULDs work well with establishing limits. Also, you can't regularly transmit on an average interval. That doesn't make sense. You can transmit a message refresh often, or frequently, or "at an average interval of 10 seconds". But "regularly" implies a fixed frequency. Otherwise it's not regular. Yes, I am a pedant. :-) > >> 4.8.2 "In addition, XML character entities are counted as a single character." >> Isn't the RTT editing calculated before XML encoding in the sender and >> after XML decoding in the recipient? This statement seems redundant >> (or worse, misleading) to me. > > > That's correct. > The sentence is there if there are any implementations that needs to encode/decode entities manually. (I don't think there are any). > (e.g. low level implementations) Is it possible that instead of "In addition", you may mean "In particular", or "These rules imply that"? >> Discovery for MUCs isn't covered - I think it needs to be; blithely >> sending RTT to an unsuspecting MUC would not be good. >> >> 6.4.4 - the seqs here aren't sequential - is that deliberate? > > > Correct. event='new' and event='reset' are allowed to restart the 'seq' numbering at any number, as mentioned in 4.3 Processing Rules. > If this was unclear, let me know how to tweak this. It's unclear - Kev got caught out. But this is a golden opportunity to pick it out and highlight it. Put a note with a pointer in, something like: Note that the seqs here are not sequential; as detailed in Section 4.3, the numbering may be restarted at any number by the event=new and event=restart. (Although I'm doing this without reading the XEP itself, note, so might be talking rubbish.) As a general note, while I do think the spec is improving, any time you manage to confuse someone like Kev, it strongly suggests there's more work to do. You can't always avoid the Kevins of this world asking you for rationale, of course - though some rationale often helps people "get" the specification - but the basic mechanics of what you're describing really have to be clarity itself purely from the XEP itself. Keep going - it's a complex protocol extension you've bitten off, but it's clearly getting there. Bet you wish you'd started on something simpler, now. :-) Dave.
