[standards-jig] Stream Contexts

Jan Niehusmann jan at gondor.com
Thu Jun 26 18:54:48 UTC 2003


On Wed, Jun 25, 2003 at 10:44:43AM -0500, Thomas Muldowney wrote:
> I'm sorry, but what is the SI JEP doing?  Or is "context", which you
> never fully explain, something magically different?

I didn't understand what's wrong with SI, either. Talking with Justin,
at least one point came up where JEP 95 is lacking a clear definition:

| 4.2 Stream Interaction
| 	[...]
| 	Initiation to the stream. The id attribute transported on the
| 	<si> element is intended to do this. Once a session is fully
| 	negotiated, the value of the id attribute is used during the
| 	actual stream negotiation as the sid attribute, or equivalent.
| 
| 4.3 <si> Explanation
| 	[...]
| 	* id - An opaque identifier generated by the Sender.

What happens if the id chosen by the sender isn't suitable as a sid 
for the chosen stream protocol?

For stream types that have an opaque ASCII identifier, this is not a
problem, because any string chosen by the sender can be used as a sid as
well. But what about streams that don't have such an identifier? Doesn't
happen? Don't be too sure.

To make JEP 95 work, the requirement of an opaque identifier should be
clearly stated. So what about adding the following sentence:

"To be compatible to this JEP, a stream protocol MUST define a stream
identifier, which MUST have a unique ASCII representation. The stream
protocol MUST be able to use any ASCII identifier chosen during 
Stream Initiation, as long as the sending party doesn't use the same
identifier more than once."

Rationale for the second sentence: The stream protocol may not limit the 
valid identifiers to some kind of structured ASCII strings. For example,
just using TCP connections, any TCP connection has a stream identifier
(source ip+port, destination ip+port), and it's easy to define a unique
ASCII representation for that. (eg. "10.0.0.1:1234,10.0.0.2:2345"). So
it complies to the first sentence.
But as SI can't know in advance that this imaginary TCP stream would be
used, it can't generate an id matching that syntax.

In the end, this is not a big limitation, and as far as I know all
existing JEPs defining some kind of stream have an ASCII id chosen by
the sender.

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030626/49dbf99f/attachment.sig>


More information about the Standards mailing list