[Standards] XEP-0301 0.5 comments [Sections 1 through 5]
markybox at gmail.com
Fri Jul 27 19:00:56 UTC 2012
Unicode talk and 'seq' talk replied to, under their appropriate thread
titles -- to compartmentalize the topics better. (those are
potentially contentious items during reviews)
> "The event attribute MAY be omitted from the <rtt/> element during
> regular real-time text transmission" - what is the the alternative
> you're allowing clients, and what is "regular real-time text
> [Change made]
> Clarification made: "The event attribute is NOT required for <rtt/> when
> transmitting changes to an existing real-time message."
> I'm not fond of either MAY or not required here - it seems like the
> behaviour isn't optional in any way, but firmly defined depending on
> the content of the stanza. It's not immediately clear to me what the
> right wording is, but it seems like it should be tighter.
> (c/NOT required/NOT REQUIRED/)
> Basic Real-Time Text allows you to transmit message changes via
> Message Reset, so there are situations where you're always using an
> 'event' attribute for all <rtt/> elements.
> How can the wording be tweaked, so that circumstance is accomodated for?
> <GH> You can replace
> "The event attribute MAY be omitted from the <rtt/> element during regular
> real-time text transmission."
> "The event attribute is used in situations specified below."
"The use of <rtt/> elements without an event attribute is for
transmitting changes to an existing real-time message. The event
attribute is used in the situations specified below:
Note: I need to explain to the reader, which situations <rtt/> can be
transmitted without an event attribute, so the extra preceding
sentence becomes necessary. Some may comment I should change the
phrase "is used" to a "MUST be used". That said, I already define the
RFC2119 normatives in the table below the sentence, so that likely is
> [Comment] Some implementers will also put the real-time message in a
> separate pane, pop-up balloon, or something outside of the lineage of the
> message history. So for such implementations, the 'id' attribute matters
> less for these situations.
> <GH> I do not think it is a good habit to edit previous without indicating
> it with an id= attribute. I have a feeling that all kinds of strange mixups can occur.
> E.g. if an application provides history for the rtt. So, I am leaning towards not allowing edit last without support of id=.
It's a very edge case, and even that edge case can be resolved by
determining if the suceeding <body/> is a <replace/> event. This
allows post-processing of linking real-time text to the correct
message, without the help of an 'id' attribute.
I agree on making it a SHOULD, but not a REQUIRED.
More information about the Standards