[Standards] XEP-0301 0.5 comments [Sections 6 and beyond]

Mark Rejhon markybox at gmail.com
Tue Jul 24 22:19:48 UTC 2012


Ok, plenty of agreements in this specific thread -- good...

On Tue, Jul 24, 2012 at 6:08 PM, Gunnar Hellström <
gunnar.hellstrom at omnitor.se> wrote:

>  <GH2>This discussion is just about a discrepancy between 6.1.4, 4.1 and
> 4.4.
> 6.1.4 says " In addition, it is acceptable for the transmission interval
> of <rtt/> to vary, either intentionally for optimizations, or due to
> precision limitation."
> 4.1 says "The <rtt/> element is transmitted at regular intervals "
> 4.4 says "For the best balance between interoperability and usability,
> the default transmission interval of <rtt/> elements for a
> continuously-changing message SHOULD be approximately 0.7 second."
>
> It looks most consistent for the logic to just delete "either
> intentionally for optimizations, or due" from 6.1.4.
>

I'll give this a re-reading (mind you -- it's a minor matter, compared to,
say, merger of <e/> and <d/>)


>      <GH2>OK for inserting Business rules and moving most of 6 to it.
>

I'll assume that this is the way to go, unless somebody from XSF advises
otherwise.

[snip]

>  <GH2>OK, covered above.
>
[snip]


> <GH2>The specification begins to be overspecified with what you can do if
> you do not want to follow the main idea. You are right, you can do as the
> second paragraph of 6.4.4 says, but it has risks that it occasionally
> creates unfavorable user experience. I think you should leave to the
> creative reader to create such odd usage combinations of the protocol
> elements.
>
> So, I still propose to delete the second paragraph of 6.4.4.
>

Might be valid.  I'll make a private consultation with that vendor, and see
if there's any issue.
Also, I'd like to hear from others at XSF, too.


<GH2>And what is the conclusion then? I would not like to discourage from
> use in MUC.
>

Simple: It's why it's not a good idea to quote predicted server load
factors for XEP-0301, without a reference to a paper first.


<GH2> I think it belongs to Business rules.
>

I am starting to agree, too.  Any comments from others about moving MUC to
a "Business Rules" section, or keeping it down there as an Implementation
Note?

[snip]

> <GH2> Good
>
[snip]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120724/5a8cc4d2/attachment.html>


More information about the Standards mailing list