[standards-jig] JEP-0045 Suggestions

Peter Saint-Andre stpeter at jabber.org
Fri Sep 13 11:55:51 CDT 2002


Hi Paul,

Thanks for the feedback. I'm tied up today but will look at this tonight
or over the weekend. Overall we do need to figure out versioning (here and
in general within Jabber), so this might be a good place to start. :)

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.html

On Fri, 13 Sep 2002, Paul Curtis wrote:

> In defining a newer "multi user" chat protocol, I realized that any 
> additions have to be backwardly compatible (at a packet level) to the 
> older "GC 1.0". In order to do this, and make the transition as painless 
> as possible, I have some suggestions for additional attributes and tags 
> that will help both client and transport developers.
> 
> In section 2.1, Joining a Room:
> 
> In order to make assist the transport writer in identifying clients that 
> can handle the newer protocol, I would suggest an attribute to be added 
> to the initial presence packet from the client that indicates a version 
> of multi-user chat that the client supports.
> 
>     eg.
>     <presence to='coven at macbeth/thirdwitch' mcversion='2'/>
> 
> By placing an attribute in the initial presence, the client would not 
> "break" the current multi-user chat component (conference-0.4x). 
> However, a newer component would check for this attribute and 
> definitively know that the client can use the newer protocol. Current 
> clients do not send this attribute, and by its absence, the component 
> developer will know that the client only supports the older "GC 1.0".
> 
> So, how does the client know that the component can provide the newer 
> protocol? Well, the current version of the JEP does not specify how the 
> room subject is sent to the client. I would suggest that the room 
> subject packet be formalized to allow client developers to know how to 
> handle the subject. In addition, this packet could be used to return the 
>   version of multi-user chat component to the user.
> 
>     eg.
>     <message type='groupchat' to='crone3 at shakespeare/pda'
>     from='coven at macbeth/firstwitch'>
>        <mcversion>2</mcversion>
>        <subject>Thrice the Cat has mew'd</subject>
>        <body>/me has set the subject to: Thrice the Cat has mew'd</body>
>     </message>
> 
>     or
>     <message type='groupchat' to='crone3 at shakespeare/pda'
>     from='coven at macbeth/firstwitch'>
>        <subject mcversion='2'>Thrice the Cat has mew'd</subject>
>        <body>/me has set the subject to: Thrice the Cat has mew'd</body>
>     </message>
> 
> The current multi-user chat component returns the above packet without 
> the <mcversion/> tag (or attribute) in it. In this manner, we do not 
> break clients that only handle multi-user chat version 1, but we provide 
> a definitive mechanism for the client to know that the additional 
> extensions are provided by the multi-user chat component.
> 
> Lastly, I would like to see attributes added to the <presence/> packets 
> for the participants in the room. These attributes should indicate 
> whether the participant is a "moderator" or "admin" or "channel 
> operator" for the room. With this information, the client developers 
> could have an indicator that shows which participants in the room are 
> capable of administering the room.
> 
>     eg.
>     <presence from='coven at macbeth/secondwitch'
>     to='crone3 at shakespeare/pda' role='admin'/>
> 
> For those client that do not support multi-user chat version 2, the 
> attribute should be ignored (or should not be sent at all) and the 
> participants' presence would appear as they do currently.
> 
> By providing concrete mechanisms for the clients and component 
> developers to indicate versioning, the possibility of incorrect behavior 
> is minimized. I have tried to find ways to implement these items in such 
> a way that the current clients will function correctly if these items do 
> not appear.
> 
> I do not like the term "mcversion" in the above examples, and I'm hoping 
> someone will suggest a better attribute/tag name.
> 
> Paul
> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 




More information about the Standards-JIG mailing list