[standards-jig] Stream Contexts
temas at box5.net
Thu Jun 26 19:04:11 UTC 2003
This is partially why I was advocating the si namespaced attribute id be
transported on the stream negotiation as si:id, but consensus was that
streams all will use their sid as an opaque identifier as well, so using
the si:id was overkill and could be reused as sid. I'll make the
wording closer to what you imagine though. The only other thing left,
that LW is going to be adding soon is a small amount of signalling which
right now will probably be start, stop and notify. Notify can be used
by the profile to provide more advanced signalling if needed, for
example, streaming audio might want pause/resume.
On Thu, 2003-06-26 at 13:54, Jan Niehusmann wrote:
> 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.
More information about the Standards