[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...

-  LW

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
>Joe Hildebrand
>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
>(hint, hint)
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 
>forward soon
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 
>automatically deferred.
>Council mailing list
>Council at jabber.org

More information about the Council mailing list