[Standards] 301 feedback

Dave Cridland dave at cridland.net
Tue Jul 2 21:03:07 UTC 2013

On 2 Jul 2013 18:47, "Mark Rejhon" <markybox at gmail.com> 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
>> 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. :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20130702/e1b5ceb4/attachment.html>

More information about the Standards mailing list