[Council] A few comments on Packet Headers

Robert Norris rob at cataclysm.cx
Mon Feb 2 21:38:11 CST 2004


I sent this to Joe, but haven't heard back from him. I too would like to
get this JEP moving, so let me know what you think.

Also, another not about the use of Infobits; I wonder if the argument
could be made that packet metadata is actually outside the scope of this
JEP? In that case, the dependency on Infobits goes away.

Rob.

----- Forwarded message from Robert Norris <rob at cataclysm.cx> -----

Date: Tue, 20 Jan 2004 09:50:55 +1100
From: Robert Norris <rob at cataclysm.cx>
To: jhildebrand at jabber.com
Subject: A few comments on Packet Headers

Just reading through the Packet Headers JEP, and I've got a few comments
which you may or may not be interested in.

 - Namespace should be changed from jabber:x:header to
   http://jabber.org/protocol/header.
 
 - 2.1 - The disco query and response should come to/from
   multicast.jabber.org, to make it match up with the other examples -
   its not clear that these are intended to be the same thing. Also, it
   might be worth noting that this can be implemented within a normal IM
   server as well as a seperate component (reading section 5 confused me
   for a moment).
 
 - 2.2 - I'd leave this out - how disco results are cached are out of
   scope for this JEP.
 
 - 3 - What is meant by a "meta-data only" request?

 - 4 - Should the use of headers be limited to only message and
   presence? I agree that that aren't particularly useful for IQs, but
   if its still allowed, then there's stuff that hasn't be documented
   that would be required for an implementation (eg how to manage
   responses).
 
 - Ex 3 - The <address> elements should have the human-readable names in
   the "desc" attribute instead of in the CDATA (according to 4.1)
 
 - 4.1 - Should it be possible for future JEPs to add types? In that
   case, a new registry probably needs to be created.
 
 - 4.2 - The dependency on Infobits is going to hold this JEP up for a
   long time. Is there any way to get around this? It might be possible
   to include this example as some sort of "non-normative" section, and
   just say that it should whatever metadata spec emerges. I can chat to
   Council about this.
 
 - 5 - This could be much clearer, IMO - I found the stuff about adding
   "delivered" attributes only to remove them later quite confusing. It
   might actually get implemented that way as some sort of optimisation,
   but it is harder to follow.
 
 - 7 - Should be changed to use XMPP errors.

 - 8 - Need a schema, obviously (not that I ever use them).

 - 9 - With the server-side groups thing, I assume you mean that I could
   send a message to server/foo, and the message would be redistributed
   by the server to everyone in the "foo" group? That, I think, might be
   outside the scope of this JEP, because if you wanted to mimic
   mailing list functionality, then you'd probably want it to be
   possible to only have the group address on the packet/headers.
 
 - An implementation note about how to build the header on replies might
   be useful, to avoid the differences in how various email clients
   handle this.
 
 - Similiarly, does anything need to be said about quoting message
   bodies? Probably not, I suspect its out of scope.

All in all, though, I think this is fine work. I'm looking forward to
implementing it, and my users will love it - sending to multiple
recipients is a core feature of the IM system I'm trying to replace, and
not being able to replicate it has been a real stumbling block.

Regards,
Rob.

----- End forwarded message -----

-- 
Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://jabber.org/pipermail/council/attachments/20040203/0842d895/attachment.pgp


More information about the Council mailing list