[Standards-JIG] Re: JEP-0124: comments on proposed version 1.5

Mridul Muralidharan mridul at sun.com
Mon May 8 15:28:49 UTC 2006


Hi Ian,

  Please see inline.

Thanks and Regards,
Mridul

Ian Paterson wrote:

> Hi Mridul,
>
>> 1) The value of '9007199254740991' for max value of rid : how was 
>> this arrived at ? On what criterion ?
>
>
> Check out note 17 from the JEP:
> "9007199254740991 is 2^53-1. Some weakly typed languages use IEEE 
> Standard 754 Doubles to represent all numbers. These Doubles cannot 
> represent integers above 2^53 accurately."


Did not notice the note - was wondering why it was either not 2^31 or 
2^63 (or thereabouts) :-)
The choice seemed a bit too arbitrary initially. Good to see that the 
schema is getting tightened !

>
>> 2) Why are you allowing arbitrary xml stanza's to be sent through 
>> connection manager ?
>
>
> Why not? :-)
>
> JEP-0124 defines a pipe through which XMPP may flow. Like TCP, 
> JEP-0124 is not XMPP (perhaps it will be an RFC one day). It is up to 
> the XMPP server and client to verify that the XML they receive through 
> the JEP-0124 pipe is valid XMPP (in the same way they already do for 
> standard 5222 TCP connections).
>
> That said, nothing in the JEP prevents a specific implementation 
> limiting itself to XMPP.
>
>> I am not sure why we are envisioning jep124 http binding connection 
>> manager as a generic xml stream gateway - if specific implementations 
>> want to treat it that way, it is fine.
>
>
> Yes the JEP simply makes sure implementations can treat it that way. 
> As commited as we are to XMPP, it is probable that other streaming XML 
> streaming protocols will be developed in the future that could benefit 
> from all the existing JEP-0124 proxy implementations that were 
> originally developed for use with XMPP.
>
> The origin of the polling-free technology now documented in JEP-0124 
> was a proprietary AJAX technology (not just for XMPP). I never 
> intended the technology to be limited to XMPP - and have not yet heard 
> a good reason to limit it.
>
> If the developers of a specific implementation want to prevent its use 
> for anything other than XMPP then that is fine. However, IMHO an 
> organisation commited to openness and extensibility should not 
> encourage that without very good reasons.


I have nothing against generic xml stanza's being transmitted over the 
negotiated http session (heck , I was also envisioning the same and have 
been pushing others to use a 124 based approach :-) ).
But considering that we are primarily targeting XMPP , it would be 
appropriate if  'allow generic xml stanza' is something which gets 
negotiated by both sides.
At the minimum , clients should assume that it is possible to transmit 
generic stanza's only if http connection manager explicitly indicates 
support for it in some way.
This is something which will be necessary for any xml stream to http 
bridge : you will need to define the stanza's that will be acceptable 
... saying that all xml stanza's will be accepted would not be good idea 
: you will have no way to enforce validation.
So , in our case the accepted stanza's would be all that is legal under 
xmpp and nothing else and imo this should be the default.
This single change has made the current JEP 124 completely backwardly 
incompatible.

By the way , I dont think we can assume that http connection manager is 
going to be 'dumb' and is going to just fwd data to backend server ...

Regards,
Mridul


>
> - Ian
>




More information about the Standards mailing list