[standards-jig] jep 65 - bytestream type
Ulrich B. Staudinger
chicago5 at gmx.de
Thu Jul 24 16:29:03 UTC 2003
I understand the difference between 65 and 96 and 95.and i think i
understand the interaction.
But i think the interaction is by far too complicated for plain
bytestreams with no extra information (i.e. meta tags, filesize, filename).
all i just want to set up is, a plain bytestream without overloaded
session negotiation. first negotiation with 95 about data exchange,
second with 65 about stream proxy. for sure i agree 96 is needed - no
offense and definitely no arguing from my side, but i think it is clear
that complexity increases with every negotiation.
Very basic clients don't want to go through 96 *and* 65 just to set up a
proxied session. That would be discoing twice, but they want to do the
dishes only once.
Peter Millard wrote:
>You're not quite understanding the interaction between JEP-95 and JEP-65.
>Bytestreams (jep-65) defines a TRANSPORT mechanism, it does not (anywhere)
>define the CONTENT of that stream. JEP-95 is whats used to indicate to the
>recipient what the content of the stream will be, and any other associated
>meta-data (for mp3, could be name of the artists, name of the radio station,
>etc..). You would write a new JEP which specifies a PROFILE for the session
>which defines the meta-data and allowed "stream" transports. This is what JEP-96
this is exactly what i want to omit - protocol complexity.
>If you want to define GSM transfers, or MP3 streams, you would write a JEP for
>those. This makes the most sense, since my client may support JEP-65, but
>doesn't know what to do with specific content coming over the stream. By having
>seperate "feature" elements to check for in a disco request/response, you can
>see if my client even supports the CONTENT you want to send me before you
>actually attempt the transfer.
if a client 'just ' supports general bytestreams, a discoing client
recieves no supported namespace in return to a disco query.
example: message exchange with use of 95,96 and 65 in best case
(omitting steps between 6&7 due to system parameters, or the like) with
one unique value for the id attribute :
1) requesting disco info from reciever
2) reciever returns disco info
3) offer stream initiation
4) return, yes i want to use bytestream
_switching to 65_
5) initiator sends service dico request
6) target replies to service disco request
7) initiator gets network adress from proxy
8) proxy informs initiator
9) initator informs target
10) target notifies initiator
11) initator req activation
12) proxy informs initiator
quite long ...
i think, to omit 4 steps by adding optional subnodes (i.e. contenttype
or other oneword description) to jep65's namespace and thus omitting
jep95/96 for simple streams is worth more than a thought.
example how a query return could look like:
<iq type='result' from='target at host2/bar' to='initiator at host1/foo'
id='hello'> <query xmlns='http://jabber.org/protocol/disco#info'>
now, if a node doesn't support a subspace the subspace is simply not in
the disco-return list.
>Hope that helps.
>Ulrich B. Staudinger wrote:
>>Yes, i know 65 has settled already. but it makes no sense for me to
>>negotiate twice if everything can be done in a single negotiation
>>session. every negotiation session increases chances of error occurance.
>>enhancing 65 to include a stream type as a subspace/subnode would really
>>help a lot, not only for possible session merging which can come at a
>>later point. it would allow stream blocking, too. for example, some
>>proxys just allow gsm traffic (which has very low bandwidth req) while
>>other proxys allow all sorts of bytestreams (the topnode bytestream).
>>i.e. /bytestream, /bytestream/gsm, /bytestream/h323, /bytestream/tradedata.
>>i really see sense in adding a subspace into the bytestream domain and
>>it would not break up existing implementations.
>Standards-JIG mailing list
>Standards-JIG at jabber.org
Ulrich B. Staudinger
jid: uls at dtedu.net
More information about the Standards