[Council] A few comments on Packet Headers
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.
----- 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
- 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
- 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
- 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.
----- 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
Size: 189 bytes
Desc: Digital signature
Url : http://jabber.org/pipermail/council/attachments/20040203/0842d895/attachment.pgp
More information about the Council