[standards-jig] jep 65 - bytestream type

Peter Millard me at pgmillard.com
Thu Jul 24 15:34:21 UTC 2003


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

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.

Hope that helps.

pgm.

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.





More information about the Standards mailing list