[Council] New Year, Time to Work
Matthew A. Miller
linuxwolf at outer-planes.net
Mon Jan 19 17:07:02 CST 2004
Since you put such a nice list together, I'll just respond to it (-:
The rest of my response is inline...
Peter Saint-Andre wrote:
>18 (Invisible Presence) -- superseded by 126 (Invisibility)
I think JEP-0018 can safely go obsolete once we move forward on
JEP-0126...and have some implementations (-:
>33 (Packet Headers) -- possibly ready for Last Call, will follow up with
>71 (XHTML-IM) -- I'm still working this with the W3C, we should have
>more progress on the schema work soon
>72 (SOAP over Jabber) -- no opinion
I had an opinion at one time, but now I don't. I believe the author has
been working on an implementation, and adjusting the JEP to suit.
>79 (Advanced Message Processing) -- Matt? shall we move forward on this
>as-is, or is there more feedback to incorporate?
There are a few more changes that need to be made, and something still
needs to be done to help resolve the pathing issue (e.g. how to
determine if all the servers between me and recipient support this). I
believe the latest revision has been posted to the JEP list, though.
>80 (Geoloc) -- somewhat dependent on the infobits vs. namespaces debate
>85 (Chat State Notifications) -- I still maintain that this is the way
>to go, but IIRC no consensus was reached previously
I personally like this better than x:events, mostly because it is very
simple. If Julian or someone can show how to do CSN in x:events, then
my opinion might change...
>86 (Legacy Errors) -- Last Call can begin once XMPP Core advances
This JEP is a very welcome addition, and helps provide heterogeneous
environments with a graceful guide for handling both. Hopefully we can
move forward with this soon! (-:
>100 (Gateway Interaction) -- I'd like to move forward on this, but it
>would be quite helpful to receive feedback from gateway developers first
I noticed there was a lot of discussion of this on standards-jig, but
woefully few comments from gateway/transport implementors...
Temas, pcurtis? I believe you've both implemented transports...any
>103/104 (URL Address etc.) -- Matt?
I believe JEP-0103 is ready to go, but JEP-0104 needs a reading to make
sure it's properly aligned with its dependencies.
>105 (Tree Transfer) -- still seems useful to me; shall I ping Ryan?
>106 (JID Escaping) -- I don't see a strong need or push for this
To me, this looks like a client-side solution to an enterprise problem.
I think the authors should probably state the expected usage, and make
sure it really covers a large enough subset of the character prohibited
in the various -preps.
>107/108/118 -- infobits vs. namespaces again
>109 (Vacation Messages) -- Matt says this could be a command (JEP 50),
>and I guess I kinda agree
I stand by the assertion this is better done with commands/x:data than
with a custom protocol (-: What is done in vacation messages could very
well be done in commands, and without requiring the client implementors
to invent yet another handler/interface (once you have commands
implemented, that is).
I'm looking at this from the perspective of the "requester-side"
implementation. While using a custom XML protocol can be easier, it
means that every requester would need to implement that protocol, and do
so for each other similar protocol. Instead, if this were based on
commands, then requesters would only need to implement that, and the
next similar protocol to come along would require little or no addition
If necessary, I'll try to put together (or help put together...) a
sample exchange to the current use-cases.
Anyway, that's my argument for moving to commands for JEP-0109.
>111 (TINS) -- needs to be revised in light of changes to IETF specs
>113 (Simple Whiteboarding) -- I'm expecting a JEP submission for
>whiteboarding with SVG, which I think is a preferable approach
>115 (Client Capabaility) -- I like this one and think it can move
My only nit is that it would be nice to use a word other than "client"
(such as "device" or "entity"). Yeah, it is super minor, but it is also
a perception thing. The word "device" (or "entity" or whatever) is
often perceived to mean that anything that can generate presence can do
this, while "client" is often perceived to mean that this is only
something for presence-generating clients (is there any other type? (-:
) to implement.
>116 (Encrypted Sessions) -- controversial; personally I like this
>approach but I know others don't; also I would like to abstract the
>chat-session negotiation piece out of this, because there is interest
>in being able to negotiate chat sessions more generally among some folks
>I've talked to (e.g., Internet2)
>120/121/123/125 -- infobits stuff, need to have a conversation about
stpeter and I have been talking, and we will have something new to
present sometime soon.
>123 (Data Form Validation) -- Matt?
I think this is ready to move forward. I have an implementation of
this, and it's working very, very nicely.
>124 (HTTP Transport Binding) -- I'll chat with Diz about this
The only question I have is on startup, and how to reconcile with SASL.
Otherwise this looks to be a better use of HTTP than JEP-0025, but not
(yet?) a complete replacement.
>126 -- <presence type='invisible'/> must die
Agreed, as stated above.
>Anything not mentioned above is, I think, on the road to being
>Council mailing list
>Council at jabber.org
More information about the Council