[Standards] 301 feedback

Kevin Smith kevin at kismith.co.uk
Tue Jul 2 20:12:26 UTC 2013

On Tue, Jul 2, 2013 at 6:46 PM, Mark Rejhon <markybox at gmail.com> wrote:
> On Tue, Jul 2, 2013 at 12:23 PM, Kevin Smith <kevin at kismith.co.uk> wrote:
>> 4.2.2  - I'm aware than we've had debates in the past about how much
>> needs to be MTI. As things currently stand, the XEP is fairly clear
>> and straightforward, and I wonder if making all of these MTI would be
> MTI?

Mandatory To Implement.

>> 4.7 "For implementation simplicity, recipient clients MAY track
>> incoming <rtt/> elements per bare JID <localpart at domain.tld> to keep
>> only one real-time message per sender"
>> Would this really help implementors? Trying to do bare-JID only seems
>> like it's going to involve more complexity and headache than doing
>> full-JID.
> To the contrary;

OK. I think this is conflating single-window and bare-JID, but it's
not a big issue.

>> 4.7 "Alternatively, recipient clients MAY keep track of separate
>> real-time messages per full JID <localpart at domain.tld/resource> and/or
>> per <thread/> (Best Practices for Message Threads [9])."
>> I think that some of the earlier instructions will be incompatible
>> with having multiple RTT messages per full-JID. It would be worth
>> someone else checking.
> To the contrary.  It's rather simple: Test the use-case.
> In a client that supports multiple RTT messages per window, both B1 and B2
> would be displayed simultaneously on A in the above use-case example.   The
> only difference to the UI would be B1 replacing B2, and vice-versa (4.7
> processing), versus B1 and B2 being displayed at the same time.   There is
> thusly, no incompatibility.
> Also, it's already been checked several times.
> Please try the implementations before discussing this matter

This isn't really the way it works - the spec stands on its own,
independent of implementations.

> you are slightly confused in this matter

Very possible, I'm easily confused.

I'll re-read when I have a chance.

>> 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).

If you have s/SHOULD/MUST/, it's not possible for any compliant client
to do anything other than regular 10 second intervals.

I think I understand what you're trying to say now, though. I'm not
sure what the best way of expressing it is.

>> 6.2.1 "it is inappropriate to send any further <rtt/> elements, until
>> support is confirmed either by incoming <rtt/> elements or via
>> discovery."
>> This needs to be normative somewhere, I think, that clients MUST NOT
>> start transmitting RTT edits until support has been confirmed. I don't
>> think the non-normative information note here is going to be sufficient.
> Section 5.1 of XEP-0085 allows transmitting of XEP-0085 without determining
> support.   I am merely simply being consistent with that, by permitting only
> a single <rtt event='init'/> to be transmitted so that I'm fully compatible
> with combining XEP-0301 with XEP-0085 in every single situation that
> XEP-0085 can be used.   There has also been long discussions in the past to
> this aspects, and this was an acceptable decision that was reached by
> majority (albiet, not by everyone) -- consistency with XEP-0085 use cases.

I think you're addressing a different point to the one I'm making.

I'm saying that the rule you've got needs to be normative - *not* that
the rule allowing you to send an init is wrong (I know you have strong
feelings on the latter).

<Sorry, had to go out here for a couple of hours, finishing the mail now>

>> 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.

One line pointing to 4.3 would probably help - I missed this even
though I was reading the whole thing through.


More information about the Standards mailing list