[standards-jig] JEP-0045 Suggestions

Fri Sep 13 08:50:55 CDT 2002

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