[Council] f/t Jingle

Kevin Smith kevin at kismith.co.uk
Wed Aug 31 09:10:56 UTC 2011

I'm +0 on 260 and 261 (which I think are my outstanding votes) having,
finally, reviewed and checked that Tobias is happy with the resolution
of his threads, although I note that 260 has a bunch of non-protocol
normative language that may or may not be appropriate (talking about
SHOULD use UPnP and things).

I'm not entirely happy (but won't block on) the following:

"A client SHOULD try the offered candidates in the order of their
priority, from highest to lowest."

Why is this only a SHOULD?

"If more than one <candidate/> element is present in a
session-initiate or session-accept, a client SHOULD wait 200ms before
trying the next one."

This isn't clear (to me) whether it means before trying (happy
eyeballsish) several connections at once, or waiting 200ms after
failure. It's also not clear to me that this is a protocol rather than
implementation decision.

"If the other party offered a direct connection and a proxy
connection, its peer MAY wait a little bit longer than 200ms before
trying the first proxy."

I don't really know why this needs specifying explicitly, but it
doesn't seem to do harm.

"A client SHOULD NOT wait for a TCP timeout on connect. If it is
unable to connect to any candidate within 5 seconds it SHOULD send a
candidate-error to the other party."

This seems wrong.

The security considerations, which I was very tempted to -1 on, seem
to be requiring that you start the file transfer before any user
input, which seems very wrong - both on being the wrong thing to do,
and mandating UI in the XEP. It could be that I'm misreading this, but
if I read it this way there's a fair chance others will, and I don't
think this is right.

The SHOULD requirement on XTLS in both XEPs doesn't seem realistic
(expired 2009?).

I'd also like to remind Nathan that his votes are due, IIRC, in the
next few hours.


More information about the Council mailing list