[Jingle] XEP-0177 : What is the "received" informational messagefor ?

[Detlev Casanova]

Hi,
I have a problem with the Raw UDP transport method.
It concerns the case when I have multiple contents using raw-udp transport
method.
When an entity sends me a received informational message, how can I find out
for which content this message is ?

Also, when I receive data, I SHOULD send this message, if one entity does not
send the message, how do I know when I can send the session-accept action ?

I was thinking of establishing the connection for each content individually
and send a session terminate if one of the contents cannot be established
after 30 seconds (for example) but as the received message SHOULD be sent,
the connection could be established and I don't know about it.

In advance, thanks.

Cheers,

Detlev.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkh/HLkACgkQLw23C4DvRJXVGgCfd/6jzxXGaURe+o3MDRxbFouu
f2AAoKySKkanmETZNsUhHybpJsoH0WBO
=n3eJ
-----END PGP SIGNATURE-----

[Jeff Williams]

Forgot to mention that Detlev's noted example from XEP-0177 doesn't
pass validation.

Jeff

On Jul 17, 2008, at 03:19 , Detlev Casanova wrote:

> Hi,
> I have a problem with the Raw UDP transport method.
> It concerns the case when I have multiple contents using raw-udp
> transport
> method.
> When an entity sends me a received informational message, how can I
> find out
> for which content this message is ?
>
> Also, when I receive data, I SHOULD send this message, if one entity
> does not
> send the message, how do I know when I can send the session-accept
> action ?
>
> I was thinking of establishing the connection for each content
> individually
> and send a session terminate if one of the contents cannot be
> established
> after 30 seconds (for example) but as the received message SHOULD be
> sent,
> the connection could be established and I don't know about it.
>
> In advance, thanks.
>
> Cheers,
>
> Detlev.

[Jeff Williams]

This won't make any sense until the moderator clears the relevant
message to the list. (That message has attachments that flagged it
for review.)


On Jul 18, 2008, at 15:35 , Jeff Williams wrote:

> Forgot to mention that Detlev's noted example from XEP-0177 doesn't
> pass validation.
>
> Jeff
>
> On Jul 17, 2008, at 03:19 , Detlev Casanova wrote:
>
>> Hi,
>> I have a problem with the Raw UDP transport method.
>> It concerns the case when I have multiple contents using raw-udp
>> transport
>> method.
>> When an entity sends me a received informational message, how can I
>> find out
>> for which content this message is ?
>>
>> Also, when I receive data, I SHOULD send this message, if one
>> entity does not
>> send the message, how do I know when I can send the session-accept
>> action ?
>>
>> I was thinking of establishing the connection for each content
>> individually
>> and send a session terminate if one of the contents cannot be
>> established
>> after 30 seconds (for example) but as the received message SHOULD
>> be sent,
>> the connection could be established and I don't know about it.
>>
>> In advance, thanks.
>>
>> Cheers,
>>
>> Detlev.
>
>

[Jeff Williams]

Hi,

From the schemas and examples it seems ambiguous which way this is
supposed to go because of the use of namespace="##other" and then our
use of <element> for type definitions at the top-level of the XSDs.
Since I've always had trouble wrapping my brain around Jingle's
complex set of XSDs I took Detlev's email as a prompt to run it all
through an XML document validator.

I've attached a complete set of files that represent all of the Jingle
examples (xep0166-examples.xml, xep0167-examples.xml, etc.) and the
XSDs needed to validate them. I placed XML comments in all of the
files where there was a problem with validation. Look for <!-- spec-
error - xxxx -->. I won't be at the conference next week, but could
someone review these validation failures to see if they're real or
not, and decide what, if anything, we should do about them. NB: There
are exceptions in the XMLs and the XSDs.

Regarding the use of <element> for type definitions at the top of the
XSDs: is there any way we can adopt a slightly different methodology
that enforces the hierarchy suggested by the examples? The change is
minor, and you can look the attached jingle.xsd for an example. This
way when you include the jingle namespace the only element you can
pull in is <jingle>, but you can still use the top-level types. This
would be true for all of the Jingle XSDs and would pin XML document
validation to be just like the examples.

Here's the high-level of what I mean...

Before:
---------------------------------------------
<xs:element name="jingle">
....
<xs:element ref="content"/>
<xs:element ref="reason"/>
....
</xs:element>
<xs: element name="content"/>
<xs: element name="reason"/>

After:
---------------------------------------------
<xs:element name="jingle">
....
<xs:element name="content" type="contentType"/>
<xs:element name="reason" type="reasonType"/>
....
</xs:element>
<xs: complexType name="contentType"/>
<xs: complexType name="reasonType"/>

Jeff


On Jul 17, 2008, at 03:19 , Detlev Casanova wrote:

> Hi,
> I have a problem with the Raw UDP transport method.
> It concerns the case when I have multiple contents using raw-udp
> transport
> method.
> When an entity sends me a received informational message, how can I
> find out
> for which content this message is ?
>
> Also, when I receive data, I SHOULD send this message, if one entity
> does not
> send the message, how do I know when I can send the session-accept
> action ?
>
> I was thinking of establishing the connection for each content
> individually
> and send a session terminate if one of the contents cannot be
> established
> after 30 seconds (for example) but as the received message SHOULD be
> sent,
> the connection could be established and I don't know about it.
>
> In advance, thanks.
>
> Cheers,
>
> Detlev.

[Peter Saint-Andre]

Jeff Williams wrote:
> This won't make any sense until the moderator clears the relevant
> message to the list. (That message has attachments that flagged it for
> review.)

The message was too big. I've increased the message size limits.

/psa

[Peter Saint-Andre]

Jeff Williams wrote:
> Forgot to mention that Detlev's noted example from XEP-0177 doesn't pass
> validation.

Which example is that?

/psa

[Peter Saint-Andre]

Detlev Casanova wrote:
> Hi,
> I have a problem with the Raw UDP transport method.
> It concerns the case when I have multiple contents using raw-udp transport
> method.
> When an entity sends me a received informational message, how can I find out
> for which content this message is ?

Does it matter? I mean: if you have a raw UDP "connection" open, won't
most/all communications succeed?

> Also, when I receive data, I SHOULD send this message, if one entity does not
> send the message, how do I know when I can send the session-accept action ?

I think we need to change SHOULD to MUST.

> I was thinking of establishing the connection for each content individually
> and send a session terminate if one of the contents cannot be established
> after 30 seconds (for example) but as the received message SHOULD be sent,
> the connection could be established and I don't know about it.

/psa

[Peter Saint-Andre]

Jeff Williams wrote:
> Hi,
>
> From the schemas and examples it seems ambiguous which way this is
> supposed to go because of the use of namespace="##other" and then our
> use of <element> for type definitions at the top-level of the XSDs.
> Since I've always had trouble wrapping my brain around Jingle's complex
> set of XSDs I took Detlev's email as a prompt to run it all through an
> XML document validator.

Thanks for doing that.

> I've attached a complete set of files that represent all of the Jingle
> examples (xep0166-examples.xml, xep0167-examples.xml, etc.) and the XSDs
> needed to validate them. I placed XML comments in all of the files
> where there was a problem with validation. Look for <!-- spec-error -
> xxxx -->. I won't be at the conference next week, but could someone
> review these validation failures to see if they're real or not, and
> decide what, if anything, we should do about them. NB: There are
> exceptions in the XMLs and the XSDs.

I'll do that soon.

> Regarding the use of <element> for type definitions at the top of the
> XSDs: is there any way we can adopt a slightly different methodology
> that enforces the hierarchy suggested by the examples? The change is
> minor, and you can look the attached jingle.xsd for an example. This
> way when you include the jingle namespace the only element you can pull
> in is <jingle>, but you can still use the top-level types. This would
> be true for all of the Jingle XSDs and would pin XML document validation
> to be just like the examples.
>
> Here's the high-level of what I mean...
>
> Before:
> ---------------------------------------------
> <xs:element name="jingle">
> ...
> <xs:element ref="content"/>
> <xs:element ref="reason"/>
> ...
> </xs:element>
> <xs: element name="content"/>
> <xs: element name="reason"/>
>
> After:
> ---------------------------------------------
> <xs:element name="jingle">
> ...
> <xs:element name="content" type="contentType"/>
> <xs:element name="reason" type="reasonType"/>
> ...
> </xs:element>
> <xs: complexType name="contentType"/>
> <xs: complexType name="reasonType"/>

Probably I haven't done things that way because I've been too lazy, but
it seems reasonable to me.

/psa

[Jeff Williams]

Hi Peter,

The XEP-0177 example 5 & 6 don't validate given the existing
namespaces. These are the examples from the spec that cover the case
that Detlev wants clarified. The XML document validator returns
"Invalid content was found starting with element 'trying'.

If you open the example and XSD files you'll see that I marked where
they don't pass validation. (Look for "spec-error".) Most of the
time it's just typos or missing (implied) pieces. In this case of
these examples the namespace is not quite right.

Also, do you have a position on having exactly one top-level element
in each XSD/namespace (with top-level complexType defining types from
that name namespace.) This way we force valid documents to adhere to
the structure implied in the examples. As XEP-0166 stands the
following XML document is well-formed and valid:

<!-- XEP-0166 example 1 -->
<iq from="kingclaudius (AT) shakespeare (DOT) lit/castle" id="jingle1" to="laertes (AT) shakespeare (DOT) lit
/castle" type="set">
<content xmlns="urn:xmpp:tmp:jingle" creator="initiator"
name="JMF"></content>
</iq>

Jeff

On Jul 27, 2008, at 19:01 , Peter Saint-Andre wrote:

> Jeff Williams wrote:
>> Forgot to mention that Detlev's noted example from XEP-0177 doesn't
>> pass validation.
>
> Which example is that?
>
> /psa
>

[Peter Saint-Andre]

Jeff Williams wrote:
> Hi Peter,
>
> The XEP-0177 example 5 & 6 don't validate given the existing
> namespaces. These are the examples from the spec that cover the case
> that Detlev wants clarified. The XML document validator returns
> "Invalid content was found starting with element 'trying'.

Right, because the core Jingle schema doesn't include something like
this for the <jingle/> element:

<xs:any namespace='##other' minOccurs='0' maxOccurs='unbounded'/>

> If you open the example and XSD files you'll see that I marked where
> they don't pass validation. (Look for "spec-error".) Most of the time
> it's just typos or missing (implied) pieces. In this case of these
> examples the namespace is not quite right.

In general I think the problem is that the ability to include any
element qualified by any namespace is implicit throughout XMPP. If we
included <xs:any namespace='##other'/> everywhere it's possible, our
schemas would be much longer and more confusing.

> Also, do you have a position on having exactly one top-level element in
> each XSD/namespace (with top-level complexType defining types from that
> name namespace.) This way we force valid documents to adhere to the
> structure implied in the examples.

That is the desired outcome. I'll need to clean up all the schemas along
those lines. Big job.

> As XEP-0166 stands the following XML
> document is well-formed and valid:
>
> <!-- XEP-0166 example 1 -->
> <iq from="kingclaudius (AT) shakespeare (DOT) lit/castle" id="jingle1"
> to="laertes (AT) shakespeare (DOT) lit/castle" type="set">
> <content xmlns="urn:xmpp:tmp:jingle" creator="initiator"
> name="JMF"></content>
> </iq>

Yeah that's not what we want. :/

/psa

[Detlev Casanova]

On Monday 28 July 2008 04:26:17 Peter Saint-Andre wrote:
> Detlev Casanova wrote:
> > Hi,
> > I have a problem with the Raw UDP transport method.
> > It concerns the case when I have multiple contents using raw-udp
> > transport method.
> > When an entity sends me a received informational message, how can I find
> > out for which content this message is ?
>
> Does it matter? I mean: if you have a raw UDP "connection" open, won't
> most/all communications succeed?

No, because a port could be blocked. If you want to send five contents on
ports 9000, 9002, 9004, 9006 and 9008 but the port 9004 is already in use by
another application and 9008 is blocked by a firewall, the connection won't
be established for those ports but will be for the 3 others.

Now, if I understand this XEP is there for testing purpose and will actually
never be used in real life as ICE-UDP can established a RAW UDP stream if it
is possible.

> > Also, when I receive data, I SHOULD send this message, if one entity does
> > not send the message, how do I know when I can send the session-accept
> > action ?
>
> I think we need to change SHOULD to MUST.
>
> > I was thinking of establishing the connection for each content
> > individually and send a session terminate if one of the contents cannot
> > be established after 30 seconds (for example) but as the received message
> > SHOULD be sent, the connection could be established and I don't know
> > about it.
>
> /psa

Cheers,

Detlev Casanova.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkiNoi8ACgkQLw23C4DvRJUEGgCfUiCB/1ig3Oa+xoWIs6gpSCQC
oZcAoI4gfTmNW+VuAMTTt2mGdPC3786z
=nRAu
-----END PGP SIGNATURE-----