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