[standards-jig] comments on JEP-0060

Tijl Houtbeckers thoutbeckers at splendo.com
Sat Jan 18 14:42:53 UTC 2003


David Sutton <jabber at dsutton.legend.uk.com> wrote on 18-1-2003 5:19:13:
>
>On Sat, Jan 18, 2003 at 02:25:44AM +0100, Tijl Houtbeckers wrote:
>> 
>> I'm not saying there should be no standard defined. I'm *not* 
>> against having an x:data standard for this. I just don't want it in 
>> the generic 
>> protocol.. because it's not generic enough. 
>>
>generic implies data encapsulation capable of different formats
>depending on the situation at hand - x:data does that. By specifying a
>standard, you're actually limiting how generic the data transfer is.
>Just a thought.

x:data could be seen as a generic solution for some situations (espc. 
after some effort is put into standardization for this). However is 
simply does not cover all situations. Note that current usage in the 
JEP is not generic at all. I think I've named enough situations where 
something else as x:data could be required, usefull or wanted. What a 
PubSub spec that does not make the usage of x:data required would reach 
is that all those different PubSub implementations will be based on the 
same common standard. (and can make use of the same additions to that 
spec. etc.) 

The JEP should be about Publish and Subscribe. The JEP does this. A 
standard for Configuration of PubSub is also needed ofcourse, but I 
don't see why it should be in the same JEP. If it is after all (fine, 
I'll learn to live with it) I don't see any reason to make it mandatory.
 If it is it's not a generic standard on PubSub. 

>> And you seriously want to take this behaviour to Jabber *and prevent 
>> other methods from being used*? 
>>
>note: in-band method I think you mean

My reason for posting was that the JEP (as it is) is completly unclear 
on the subject. I do think everyone agrees on that by now. The JEP does 
state that configuration should be possible After this the creator of 
the JEP made a statement, that all configuration MUST be done with 
x:data. He later changed this to, if configuration is *available* it 
MUST be done with x:data. 

So Peter Millard proposes we stick with x:data and nothing else. Also 
so far I've not heard him say he's in favor of a *mandatory* 
standardization of var names in the forms, since configuration can be 
"anything". 

Matthew Miller propesed that at minimum x:data should be supported but 
that any other method is allowed too. 

David Waite pointed out that thus far x:data is not ready for machine 
entry since there is no good standard on it yet. He said he has gotten 
push-back in the past when trying to establish one. Reading over what's 
been said so far in this thread I think next time he tries he'll find 
less oposition in his way :) 

Ralph Meijer proprosed that we should use x:data for in-band only, and 
that we agree on wich var names to use in them. (wether both points are 
mandatory or a recommandation is not entirely clear). 

Joe Hildebrand propesed that we change the proposed MUST of using 
x:data to SHOULD, allowing out of band and alternate in band 
configurations. 

Tijl Houtbeckers (hey that's me :) propesed that we cut this JEP in 
half, one that focuses strictly on a common generic method for 
publishing an subscribing, leaving configuration free for 
implementation. And one JEP that documents an implemantion of this 
using x:data, including (or maybe in another JEP even) a fixed set of 
fieldnames etc. If it makes people happy, there can be a (strict) 
recommendation to use x:data configuration for most cases in the first 
JEP. Maybe the <configure/> field could be reserved even for it, though 
I don't see a need for that since a seperate JEP for x:data config will 
mean it has it's own namespace. 

Tijl Houtbeckers also propesed that is this is not wanted because 
people want this stuff in one big JEP that's possible. As long as it 
still allows alternate methods. I'd prefer a strict recommendation to 
use x:data, espc. in human<->machine communication within Jabber. 

>> So I'd be absolutly willing to settle for this.. since this is all 
>> I've 
>> asking for all the time. I'm only worried your usage of the word 
>> SHOULD 
>> is not really in line with the RFC usage. It's not there to allow 
>> exceptions to a rule in this sort of way I think. MAY sounds better 
>> but 
>> I think it could be solved in a better way, if we all agree that 
>> other 
>> methods should be allowed. 
>> 
>I'd just like to point out one little flaw with the whole 'lets make
>everything so generic with different possibilities of configuration' -
>how does a client know which method to use? Are you going to code every
>possible in-band system into a client? (Note: OOB is not covered by the
>JEP, nor should it be)

(Note: statements made imply that it does cover OOB).

You're looking at it mostly from a Desktop client prespective I think. 
Well, A client would know wich methods are supported (ofcourse) by 
using Disco. Clients that don't do Disco could just asume it does and 
try, if not they'll get back an error. The only method clients will 
have to support is x:data, since this what we'll be using on "public" 
PubSub servers that people will have acces to. This won't change just 
because you other methods are allowed. Ofcourse it does mean that if 
one day we get something 10 times better then x:data for it and many 
clients support it our PubSub servers can start supporting it too. I'd 
be kind of stupid to rule that out wouldn't it? 

Ofcourse, for human<->machine communication we don't have anything is 
flexible and great like x:data we could use to configure PubSub. It's 
great, I'm all for it. I think for machine<->machine communications 
better things exist, and I could think of better ways, depending on 
what use my pubsub would have. These PubSub servers might not have a 
need for desktop clients to configure them at all. Maybe I want to use 
something different like XML-RPC. Maybe I want to use real XML so I can 
use XLST. Maybe I want to send stockquotes as configuration data. 

Would any desktop client have to support those? Ofcourse not.
Since when did *choice* become a bad thing in open standards? 

Keep in mind, even though I don't use x:data as configuration method 
any desktop client that implements JEP-0060 could still use it, just 
not configure. 

>By fixing on one data encapsulation, you make it much easier to know 
>how to send the data. You are then only having to deal with which data 
>is to be send in-band.

Again again again, I definatly think there should be a decent x:data 
way of doing this. I'm against making it mandatory, and very against 
actively suppresing other methods. If others want to do that, well 
there is nothing I can do, but I think calling it "generic" is a bit 
silly then. 

> This is only possible because the usage in MUC is static. As PGM has 
>> been saying from the start, for JEP-0060 the reason x:data has been 
>> choosen is because the configuration can be anything ("I want this 
>> JEP 
>> to show what are POSSIBLE configuration options for pubsub nodes"). 
>>
>The statement that the usage in MUC is static is flawed - The x:data
>fields given in the JEP are advisory - If an implementation wanted to
>add/remove them, there is nothing to stop them from doing that.

I'm not really talking about the JEP, much more about your component. 
Joe's program to automatically create channels works cause your client 
is in line with those advisory fields. If anyone changes them his 
program will break. 

I think Peter Millard choose to use x:data because of it's flexibility 
and because desktop clients support (answering) them. Cause at the time 
the JEP is being written (now) it's very hard to tell wich different 
configuration options will be used. When a human fills in those forms 
that's not a problem. It solves the problem for Desktop clients. 

When you take it out of this prespective, and put it in the machine<-
>machine prespective this is not valid anymore. The only way (till we 
>have that super AI) to fix this is to "strcmp". However this takes 
>away most of the reasons we choose for x:data in the first place. In 
>fact, in some cases it's valid to make the choice to do this 
>different, after all x:data is not as flexible as XML in all cases. 

>Then again, all values have predefined default values, so basic
>configuration can be done simply by sending an empty form.
>>

Sure you can do this.. I'll probably do it myself in a lot of cases. 
Doesn't mean I think other options should be forbidden. 


-- 
Tijl Houtbeckers
Java/J2ME/GPRS Software Engineer @ Splendo
The Netherlands




More information about the Standards mailing list