[standards-jig] JEP-0045 Suggestions

Fri Sep 13 14:03:14 CDT 2002

Using namespaces to differentiate between versions is a really good 
idea. I'd thought of doing the same while working on the Core Tool 
Protocol set.

Thomas Muldowney wrote:
> What about using namespaces?
> 
> Another version location alternative:
> <message xmlns:mc='http://jabber.org/JEPS/MultiChat' type='groupchat'
> to='crone3 at shakespeare/pda' from='coven at macbeth/firstswitch'
> mc:version='2'>
>   <subject> Thrice the Cat has mew'd</subject>
>   <body>....</body>
> </message>
> 
> <presence xmlns:mc='http://jabber.org/JEPS/MultiChat' 
>     from='coven at macbeth/secondwitch' to='crone3 at shakespeare/pda' 
>     mc:role='admin'/>
> 
> I think the namespaces would really allow the extra info to be more
> clearly seperated, and perhaps a nice model fo future expansion on
> existing protocol.
> 
> --temas
> 
> 
> 
> On Fri, Sep 13, 2002 at 09:50:55AM -0400, 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-ji
> 
> g

-- 
     /\  Adam Theo, Age 23, Tallahassee FL USA
    //\\   Email & Jabber: theo at theoretic.com
   //  \\  Pager: (850) 709 7738
=//====\\=
//  ||  \\  Theoretic Solutions: http://www.theoretic.com
     ||         "Building Ideas by Bringing them Together"
     ||      Jabber Protocol: http://www.jabber.org
     ||         "The Next Generation Communications Protocol"
     ||  "A Free-Market Socialist Patriotic American Buddhist"