[Standards] XEP-0301 0.5 comments [Sections 1 through 5]

Gunnar Hellström gunnar.hellstrom at omnitor.se
Fri Jul 27 20:31:03 UTC 2012

<GH>Further comments inline,
On 2012-07-27 21:00, Mark Rejhon wrote:
> 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
>> transmission"?
>> [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.
>> [Comment]
>> (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."
>> with
>> "The event attribute is used in situations specified below."
> [Change Made]
> "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
> sufficient.
<GH>Yes, it would not fit well with MUST in the introductory sentence 
and MAY for the two optional values.
Your proposed sentence looks ok to me.
>> [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.
<GH>No, please make a MUST for id=  in edit previous. I can imagine 
presentation cases when it is absolutely necessary to know what message 
the edits belong to. Why do you want to introduce so many options? 
Strict requirements are usually much more fruitful.


More information about the Standards mailing list