XSF Discussion - 2010-05-15

Hey All

hey Steffen

hola Ali :-)

again

we have three XEPs that needs to be review

• XEP-0234: Jingle File Transfer (http://xmpp.org/extensions/xep-0234.html) • XEP-0260: Jingle SOCKS5 Bytestreams Transport Method (http://xmpp.org/extensions/xep-0260.html) • XEP-0261: Jingle In-Band Bytestreams Transport Method (http://xmpp.org/extensions/xep-0261.html)

yep

k

I've only been reading the file transfer.. and only have few comments to it.. how about you: ali and joe?

what is the "normal" procedure for a review?.. does anyone know?

ah, I'm glad you asked. This is new to me as well

same here

were you part of the 45 MUC review?

ha ha.. then we are in the same boat together :-)

nope.. sorry

OK, I guess we all require some guidance on what sorts of comments are constructive

jup.. could be nice.. Ive been adding some stuff before on XEP166 (jingle) but that was before the review days

I have 234 open now. not too long. can read and at least discuss

but otherwise I was thinking that we could distribute things a bit.. so all of us three read all of the documents but one of us have a master document

that wouldn't be a bad idea

ok

but lets start with 234 together then.. have you read it ali?

yes

cool

please continue while i catch up

ha ha ;-)

:)

give me 1 min to get the coffee

back

as I read it it looks pretty clear defined.. because it already uses the deprecated 0096 xep

but there are some stuff that could be more explicit

I don't know what you think, but in section 3

E.g. the size attribute.. its apparently in bytes.. should there not be a unit on that? or should we at least write it explicitly

wouldn't it be good to have a reminder about the fact that the message must be sent while the session is not terminated ?

the hash?

yes the hash

hmm let me read

heh yeah your riight. makes sense

it's probably the "At any time" wording that might be confusing

so sending the hash from the hosting entity can onnly be done if your in an open session

jup!

yes, that's already true because of how session-info is defined in 0166

it can only be done in the right state.. taht is in a session that is not terminated yet

but its good to be explicit anyways

the same thing with the size of the file

let me read

yes, I agree

there stands nothing about the unit right?

I can't find anything

but it's bytes... from the deprecated 96 xep

how many clients out there implement socks5 bytestreams? any idea

?

ha ha.. I was thinking the same the other day.. have no idea

is there anyone?

most uses the old file transfer as well, right?

out of band

that's the only one i've seen implemented

you mean xep-065 ?

yes, 65

I think Gajim implements it

k

thx

could actually be cool to have that in the xep documents.. to see which clients/servers implement a given xep

that would be great actually

to see real life examples and find them easierly

there is some other stuff that i was wondering about in 234.. is it at all possible to resume a file transfer it you have disconnected and connects again?.. or do you have to transfer the whole file again

Looks like you'd have to start again

but this is for relatively small files, no?

normally.. ;-)

I mean.. we cant assume anything. but I would probably not transfer Ironman2 in HD

there are more effective ways there..

:)

if i understand this correctly, the sock5 bytestream is handled like a media session, in essence

Am I off or is that the basic jist?

yes

so the file goes peer to peer

socks5 is used as a transport

right

like a normal jingle

yep

its just used to set up a stream

concerning the resume transfer issue

so for organizations that need to virus scaning, or content inspection, they're out of luck

sorry Ali...

imagine a fictionnal bitorrent transport

yep

we can talk about resume

we would be able to resume the transfer at the transport layer (in this case bitorrent)

yes.. your proabably right

so it's up to the transport layer to work out that stuff

so if we were to try adding support for resuming transfers, it would probably be better done at the transport layer and not at the session management layer

:)

am I wrong ?

no that would probably be the easiest

what you are saying makes sense to me

so with the currently existing transports we have no way of resuming a transfer

i don't know enough about the transports to comment

have you seen any clients doing it?..

resuming filetransfers ?

yes

I mean xmpp clients.. not ftp and others

adium and pidgin doesnøt

does'nt

not XMPP, but iirc the MSN protocol no matter how ugly it is allows this

but it's done at the transport layer, and not at the session management layer

ok.. lets leave it there then

it would be hard to tell if an xmpp client implemented 234 or 261, wouldn't it?

in-band looks more appealing to me, from a security point of view

no not that much.. we could just sniff and see what it send when trying to fetch a file

would enable the extension of the server to inspect, etc

yes

should these three xeps but collapsed in to 1?

they are very short and so closely related

i dont think so

ok

I don't think so

event though they are related :-)

fair enough

234 defines the general protocol, while 260 and 261 define 2 transports

yes

its like 166, 167 etc.

they were together in the start but was split up

to keep it simple

that's good to know, thx

:-)

basically in theory it's possible to use xep-0166 + xep-0167 + xep-260 for a media session

yes

167 descripes the payloads as far as I remember

it describes the rtp application in the same way that xep-0234 describes file transfer as an application

k

I'm wondering about the communicating to of the hash

it says it can be done at any time

does that present a challenge for someone implementing?

while the session is open

and ensure interop?

have to see 96

looking

by the way.. where is the XSD schema for the 234?.. it seems like its using the 96 : <xs:sequence xmlns:ft='http://jabber.org/protocol/si/profile/file-transfer'>       <xs:element ref='ft:file'/> .

shouldn't we put it in explicitly so we can see the full schema?

<xs:import namespace='http://jabber.org/protocol/si/profile/file-transfer' schemaLocation='http://www.xmpp.org/schemas/file-transfer.xsd'/>

yes I see the import

but why use a deprecated schema.. why not write it there explicitly

I mean 96 will dissapear

I don't know these things are generally managed

hmmm I was just wondering

if it is meant to disappear, I think it's pretty weird that we have a reference to a deprecated xep

well I dunno..

thats why I was wondering that much.. ;-)

its in Draft..

but it seems like that in the intro of 234.. we are reusing from 96 in order to deprecate.. Or am I wrong?

that's what the intro seems to imply

I am glad that we are thinking the same.. ha ha :-)

well I will note it in my small notebook about 234.

have we anything more to add to 234?.. or shall we try to go into 260,261. the transportations?

can we make a small summary before moving on ?

yes

please

so... we need to do it more explicitly that in (hashing)"At any time" means when the session is not terminated

also to make the size more explicitly.. so the it stands bytes.

- Section 3. we need to clarify that the hash MUST be transferred within the session lifetime

great

exactly

is it a MUST transfer ?

good question

or a SHOULD transfer and MUST be done within the session lifetime

have to be MUST

SHOULD is an option

and MD5 only?

is the hash a requirement ?

a great question

I dont think so

hmm, and where does it say that it is md5 ?

"the hosting entity can communicate the hash of the file to the receiving entity.."

the magic word is "can".

so i think it is optional

so let's turn this into a SHOULD

makes sense

where should we put the unit of bytes?

the file tag is poorly described.. if we didn't have 96. ;-)

yes

hmm seems like xep-0096 had support for resuming transfers

he he he

where in 96?

<range>

where do you see it

ah

so its made in the setup protocol there

yes

so as I see it, it is not fully backward compatible.

it doesn't seem to be

hmm

that's an issue

I would say that xep-0260 needs quite a lot of improvement

yes

+1

on 234 and 96...why the requirement to implement both bytestreams and in-band?

can the implementation be in-band only, simply decline bytestream requests?

I'm thinking the corporate installations would not want 260 implemented in general

to reuse 0047

no they would probably go for the inband

again, i'm thinking interop

0047 is to be deprecated in favor of 261?

seems like it

same words used as in 234

ok, so are we on to 260?

what do you think about this summary:

Hash transfer in section 3. has a poor wording • Reusing too much of 0096: ∘ Size specification in bytes ∘ Hash algorithm == md5 • Ranged queries lost 0096 -> 0260 (but backward compatibility kept) ∘ If ranged queries are to be implemented, should be transport options/transport features

(indentations seems to have been lost)

i can see it pretty well

using Adium

oh, not me

yes.. and either we use explicit xsd in the 234 or we have a problem when deprecating 96

I see it as well (adium) :-)

Should use explicit XSD in 0234 (avoid imports) ?

yes.. Well at least I think so

+1

otherwise we seem to have a good summary

shall we write a mail with our summary to the member/tech list or just update the svn our selves?

no idea, I am new here :)

Perhaps notify the list that we met, and post results in the system

I think we're all new :)

only been here half a year.. so me too

I'd say we post to the mailing list

sorry.. my network just blow up

Welcome back

ha ha.. thanks

yeah.. lets send it to the techlist

shal I summarize it in a mail?

shall

great, yes

sure

ok.. I'll look through the XEPs again and write a summary tomorrow, ok?

Thank you!

we have nothing more to the 260,261?

perfect, thanks

np

we probably do, I have 15 more minutes

me too.. going to a dinner soon

hmm, I haven't started reviewing 260 nor 261

well if you have time we can have a small talk again tomorrow..

but I have a problem with <proxy-error>

in 260

I am afraid I won't be able to join tomorrow

ahh ok

tomorrow is difficult for me as well

what is the issue w/proxy-error?

not familiar with the xep enough, but how do you specify which proxy failed ?

in case you sent multiple proxy candidates ?

ah, i see it's too generic

do we want the protocol to tell us?

<candidate-used> has cid

isn't it hanging on a candidate?

<candidate-error> is sent when all the candidates failed

yep I see

and proxy when only one of them?

but in this case. ALL candidates have failed, right?

yes that's right

I got it wrong

:)

;)

what about we setup another meeting sometimes next week for reviewing 260 and 261 ?

good idea

because in 15 minutes we won't get much done

agree

+1

how about wedensday?

wedensday after work (CEST).. so about 19:00 CEST?

or are you too busy Joe?

we can make it later if you want

I need to fix my firewall at work for the high port

ha ha

i have to submit a ticket, wait two weeks, etc

so...

:)

one week from today could work

or very early in the AM New York time

ha ha.. can't you do it your self, and by pass all the bureaucracy? ;-)

next saturday ?

i wish!!

Swiss banks are a little fussy about security ;)

use BOSH

wait.. I'll check my calendar

yeah.. use BOSH

I'll check out a BOSH client

I made several my self.. easy wth Strophe

cool

Im fine with next saturday ... but when should the review be done?. is there a date?'

If i can get access to this room, then it can be during business US business hours

ok Joe, its up to you

so Joe, what about you send a mail sometimes during the week to setup the meeting ?

+1

:-)

ok

both Steffen and me are on the CEST timezone

ok

i'm think next Saturday, but a bit earlier

yeah.. Denmark and Norway right?

nice

yes :)

good spots in the world

yeah.. right now it is fun to watch ice hockey.. ;-)

OK, I'll send a mail....will probably be for 8:30 EDT Saturday

Thanks for your time.

yes.. just pass a mail around!

thanks everyone

thanks!

I'll send a mail around tomorrow with some of our summaries..

great

off to my son's baseball game....enjoy the rest of the weekend

thanks ! you too

I am off as well

so ttyl

?See ya later.. ciao!