[standards-jig] JEP-0045 Suggestions

Fri Sep 13 13:09:11 CDT 2002

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-jig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/standards/attachments/20020913/a0cc4f77/attachment.pgp