XSF Discussion - 2010-05-15


  1. Tobias has joined

  2. luca tagliaferri has joined

  3. Kev has joined

  4. zooldk@gmail.com has joined

  5. Joe M has joined

  6. Ali Sabil has joined

  7. zooldk@gmail.com

    Hey All

  8. Ali Sabil

    hey Steffen

  9. zooldk@gmail.com

    hola Ali :-)

  10. zooldk@gmail.com

    again

  11. zooldk@gmail.com

    we have three XEPs that needs to be review

  12. zooldk@gmail.com

    • 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)

  13. Ali Sabil

    yep

  14. Joe M

    k

  15. zooldk@gmail.com

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

  16. zooldk@gmail.com

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

  17. Joe M

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

  18. Ali Sabil

    same here

  19. Joe M

    were you part of the 45 MUC review?

  20. zooldk@gmail.com

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

  21. zooldk@gmail.com

    nope.. sorry

  22. Joe M

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

  23. zooldk@gmail.com

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

  24. Joe M

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

  25. zooldk@gmail.com

    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

  26. Ali Sabil

    that wouldn't be a bad idea

  27. Joe M

    ok

  28. zooldk@gmail.com

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

  29. Ali Sabil

    yes

  30. zooldk@gmail.com

    cool

  31. Joe M

    please continue while i catch up

  32. zooldk@gmail.com

    ha ha ;-)

  33. Joe M

    :)

  34. zooldk@gmail.com

    give me 1 min to get the coffee

  35. zooldk@gmail.com

    back

  36. zooldk@gmail.com

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

  37. Ali Sabil has left

  38. Ali Sabil has joined

  39. zooldk@gmail.com

    but there are some stuff that could be more explicit

  40. Ali Sabil

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

  41. zooldk@gmail.com

    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

  42. Ali Sabil

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

  43. zooldk@gmail.com

    the hash?

  44. Ali Sabil

    yes the hash

  45. zooldk@gmail.com

    hmm let me read

  46. zooldk@gmail.com

    heh yeah your riight. makes sense

  47. Ali Sabil

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

  48. zooldk@gmail.com

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

  49. zooldk@gmail.com

    jup!

  50. Ali Sabil

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

  51. zooldk@gmail.com

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

  52. zooldk@gmail.com

    but its good to be explicit anyways

  53. zooldk@gmail.com

    the same thing with the size of the file

  54. Ali Sabil

    let me read

  55. Ali Sabil

    yes, I agree

  56. zooldk@gmail.com

    there stands nothing about the unit right?

  57. Ali Sabil

    I can't find anything

  58. zooldk@gmail.com

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

  59. Joe M

    how many clients out there implement socks5 bytestreams? any idea

  60. Joe M

    ?

  61. zooldk@gmail.com

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

  62. zooldk@gmail.com

    is there anyone?

  63. zooldk@gmail.com

    most uses the old file transfer as well, right?

  64. Joe M

    out of band

  65. Joe M

    that's the only one i've seen implemented

  66. Ali Sabil

    you mean xep-065 ?

  67. Joe M

    yes, 65

  68. Ali Sabil

    I think Gajim implements it

  69. Joe M

    k

  70. Joe M

    thx

  71. zooldk@gmail.com

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

  72. Ali Sabil

    that would be great actually

  73. zooldk@gmail.com

    to see real life examples and find them easierly

  74. zooldk@gmail.com

    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

  75. Joe M

    Looks like you'd have to start again

  76. Joe M

    but this is for relatively small files, no?

  77. zooldk@gmail.com

    normally.. ;-)

  78. zooldk@gmail.com

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

  79. zooldk@gmail.com

    there are more effective ways there..

  80. Joe M

    :)

  81. Joe M

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

  82. Joe M

    Am I off or is that the basic jist?

  83. zooldk@gmail.com

    yes

  84. Joe M

    so the file goes peer to peer

  85. Ali Sabil

    socks5 is used as a transport

  86. Joe M

    right

  87. zooldk@gmail.com

    like a normal jingle

  88. Joe M

    yep

  89. zooldk@gmail.com

    its just used to set up a stream

  90. Ali Sabil

    concerning the resume transfer issue

  91. Joe M

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

  92. Joe M

    sorry Ali...

  93. Ali Sabil

    imagine a fictionnal bitorrent transport

  94. Joe M

    yep

  95. Joe M

    we can talk about resume

  96. Ali Sabil

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

  97. zooldk@gmail.com

    yes.. your proabably right

  98. Joe M

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

  99. Ali Sabil

    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

  100. Joe M

    :)

  101. Ali Sabil

    am I wrong ?

  102. zooldk@gmail.com

    no that would probably be the easiest

  103. Joe M

    what you are saying makes sense to me

  104. Ali Sabil

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

  105. Joe M

    i don't know enough about the transports to comment

  106. zooldk@gmail.com

    have you seen any clients doing it?..

  107. Ali Sabil

    resuming filetransfers ?

  108. zooldk@gmail.com

    yes

  109. zooldk@gmail.com

    I mean xmpp clients.. not ftp and others

  110. zooldk@gmail.com

    adium and pidgin doesnøt

  111. zooldk@gmail.com

    does'nt

  112. Ali Sabil

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

  113. Ali Sabil

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

  114. zooldk@gmail.com

    ok.. lets leave it there then

  115. Joe M

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

  116. Joe M

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

  117. zooldk@gmail.com

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

  118. Joe M

    would enable the extension of the server to inspect, etc

  119. zooldk@gmail.com

    yes

  120. Joe M

    should these three xeps but collapsed in to 1?

  121. Joe M

    they are very short and so closely related

  122. zooldk@gmail.com

    i dont think so

  123. Joe M

    ok

  124. Ali Sabil

    I don't think so

  125. zooldk@gmail.com

    event though they are related :-)

  126. Joe M

    fair enough

  127. Ali Sabil

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

  128. Joe M

    yes

  129. zooldk@gmail.com

    its like 166, 167 etc.

  130. zooldk@gmail.com

    they were together in the start but was split up

  131. zooldk@gmail.com

    to keep it simple

  132. Joe M

    that's good to know, thx

  133. zooldk@gmail.com

    :-)

  134. Ali Sabil

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

  135. zooldk@gmail.com

    yes

  136. zooldk@gmail.com

    167 descripes the payloads as far as I remember

  137. Ali Sabil

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

  138. Joe M

    k

  139. Joe M

    I'm wondering about the communicating to of the hash

  140. Joe M

    it says it can be done at any time

  141. Joe M

    does that present a challenge for someone implementing?

  142. zooldk@gmail.com

    while the session is open

  143. Joe M

    and ensure interop?

  144. zooldk@gmail.com

    have to see 96

  145. Joe M

    looking

  146. zooldk@gmail.com

    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'/> .

  147. zooldk@gmail.com

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

  148. Ali Sabil

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

  149. zooldk@gmail.com

    yes I see the import

  150. zooldk@gmail.com

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

  151. zooldk@gmail.com

    I mean 96 will dissapear

  152. Ali Sabil

    I don't know these things are generally managed

  153. zooldk@gmail.com

    hmmm I was just wondering

  154. Ali Sabil

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

  155. zooldk@gmail.com

    well I dunno..

  156. zooldk@gmail.com

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

  157. zooldk@gmail.com

    its in Draft..

  158. zooldk@gmail.com

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

  159. Ali Sabil

    that's what the intro seems to imply

  160. zooldk@gmail.com

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

  161. zooldk@gmail.com

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

  162. zooldk@gmail.com

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

  163. Ali Sabil

    can we make a small summary before moving on ?

  164. zooldk@gmail.com

    yes

  165. Joe M

    please

  166. zooldk@gmail.com

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

  167. zooldk@gmail.com

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

  168. Ali Sabil

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

  169. Joe M

    great

  170. zooldk@gmail.com

    exactly

  171. Ali Sabil

    is it a MUST transfer ?

  172. Joe M

    good question

  173. Ali Sabil

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

  174. zooldk@gmail.com

    have to be MUST

  175. zooldk@gmail.com

    SHOULD is an option

  176. Joe M

    and MD5 only?

  177. Ali Sabil

    is the hash a requirement ?

  178. Joe M

    a great question

  179. zooldk@gmail.com

    I dont think so

  180. Ali Sabil

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

  181. zooldk@gmail.com

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

  182. zooldk@gmail.com

    the magic word is "can".

  183. zooldk@gmail.com

    so i think it is optional

  184. Ali Sabil

    so let's turn this into a SHOULD

  185. Joe M

    makes sense

  186. zooldk@gmail.com

    where should we put the unit of bytes?

  187. zooldk@gmail.com

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

  188. Ali Sabil

    yes

  189. Ali Sabil

    hmm seems like xep-0096 had support for resuming transfers

  190. zooldk@gmail.com

    he he he

  191. Joe M

    where in 96?

  192. Ali Sabil

    <range>

  193. zooldk@gmail.com

    where do you see it

  194. Joe M

    ah

  195. zooldk@gmail.com

    so its made in the setup protocol there

  196. Ali Sabil

    yes

  197. zooldk@gmail.com

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

  198. Ali Sabil

    it doesn't seem to be

  199. zooldk@gmail.com

    hmm

  200. Joe M

    that's an issue

  201. Ali Sabil

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

  202. zooldk@gmail.com

    yes

  203. zooldk@gmail.com

    +1

  204. Joe M

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

  205. Joe M

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

  206. Joe M

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

  207. zooldk@gmail.com

    to reuse 0047

  208. zooldk@gmail.com

    no they would probably go for the inband

  209. Joe M

    again, i'm thinking interop

  210. Joe M

    0047 is to be deprecated in favor of 261?

  211. zooldk@gmail.com

    seems like it

  212. zooldk@gmail.com

    same words used as in 234

  213. Joe M

    ok, so are we on to 260?

  214. Ali Sabil

    what do you think about this summary:

  215. Ali Sabil

    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

  216. Ali Sabil

    (indentations seems to have been lost)

  217. Joe M

    i can see it pretty well

  218. Joe M

    using Adium

  219. Ali Sabil

    oh, not me

  220. zooldk@gmail.com

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

  221. zooldk@gmail.com

    I see it as well (adium) :-)

  222. Ali Sabil

    Should use explicit XSD in 0234 (avoid imports) ?

  223. zooldk@gmail.com

    yes.. Well at least I think so

  224. Joe M

    +1

  225. zooldk@gmail.com

    otherwise we seem to have a good summary

  226. zooldk@gmail.com

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

  227. Ali Sabil

    no idea, I am new here :)

  228. Joe M

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

  229. Joe M

    I think we're all new :)

  230. zooldk@gmail.com

    only been here half a year.. so me too

  231. zooldk@gmail.com has left

  232. Ali Sabil

    I'd say we post to the mailing list

  233. zooldk@gmail.com has joined

  234. zooldk@gmail.com

    sorry.. my network just blow up

  235. Ali Sabil

    Welcome back

  236. zooldk@gmail.com

    ha ha.. thanks

  237. zooldk@gmail.com

    yeah.. lets send it to the techlist

  238. zooldk@gmail.com

    shal I summarize it in a mail?

  239. zooldk@gmail.com

    shall

  240. Joe M

    great, yes

  241. Ali Sabil

    sure

  242. zooldk@gmail.com

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

  243. Joe M

    Thank you!

  244. zooldk@gmail.com

    we have nothing more to the 260,261?

  245. Ali Sabil

    perfect, thanks

  246. zooldk@gmail.com

    np

  247. Joe M

    we probably do, I have 15 more minutes

  248. zooldk@gmail.com

    me too.. going to a dinner soon

  249. Ali Sabil

    hmm, I haven't started reviewing 260 nor 261

  250. zooldk@gmail.com

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

  251. Ali Sabil

    but I have a problem with <proxy-error>

  252. Ali Sabil

    in 260

  253. Ali Sabil

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

  254. zooldk@gmail.com

    ahh ok

  255. Joe M

    tomorrow is difficult for me as well

  256. Joe M

    what is the issue w/proxy-error?

  257. Ali Sabil

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

  258. Ali Sabil

    in case you sent multiple proxy candidates ?

  259. Joe M

    ah, i see it's too generic

  260. Joe M

    do we want the protocol to tell us?

  261. Ali Sabil

    <candidate-used> has cid

  262. zooldk@gmail.com

    isn't it hanging on a candidate?

  263. Ali Sabil

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

  264. Ali Sabil

    yep I see

  265. zooldk@gmail.com

    and proxy when only one of them?

  266. Joe M

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

  267. Ali Sabil

    yes that's right

  268. Ali Sabil

    I got it wrong

  269. Ali Sabil

    :)

  270. Joe M

    ;)

  271. Ali Sabil

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

  272. Joe M

    good idea

  273. Ali Sabil

    because in 15 minutes we won't get much done

  274. Joe M

    agree

  275. zooldk@gmail.com

    +1

  276. zooldk@gmail.com

    how about wedensday?

  277. zooldk@gmail.com

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

  278. zooldk@gmail.com

    or are you too busy Joe?

  279. zooldk@gmail.com

    we can make it later if you want

  280. Joe M

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

  281. zooldk@gmail.com

    ha ha

  282. Joe M

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

  283. Joe M

    so...

  284. Ali Sabil

    :)

  285. Joe M

    one week from today could work

  286. Joe M

    or very early in the AM New York time

  287. zooldk@gmail.com

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

  288. Ali Sabil

    next saturday ?

  289. Joe M

    i wish!!

  290. Joe M

    Swiss banks are a little fussy about security ;)

  291. Ali Sabil

    use BOSH

  292. zooldk@gmail.com

    wait.. I'll check my calendar

  293. zooldk@gmail.com

    yeah.. use BOSH

  294. Joe M

    I'll check out a BOSH client

  295. zooldk@gmail.com

    I made several my self.. easy wth Strophe

  296. Joe M

    cool

  297. zooldk@gmail.com

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

  298. Joe M

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

  299. zooldk@gmail.com

    ok Joe, its up to you

  300. Ali Sabil

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

  301. zooldk@gmail.com

    +1

  302. zooldk@gmail.com

    :-)

  303. Joe M

    ok

  304. Ali Sabil

    both Steffen and me are on the CEST timezone

  305. Joe M

    ok

  306. Joe M

    i'm think next Saturday, but a bit earlier

  307. zooldk@gmail.com

    yeah.. Denmark and Norway right?

  308. Joe M

    nice

  309. Ali Sabil

    yes :)

  310. Joe M

    good spots in the world

  311. zooldk@gmail.com

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

  312. Joe M

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

  313. Joe M

    Thanks for your time.

  314. zooldk@gmail.com

    yes.. just pass a mail around!

  315. Ali Sabil

    thanks everyone

  316. zooldk@gmail.com

    thanks!

  317. zooldk@gmail.com

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

  318. Ali Sabil

    great

  319. Joe M

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

  320. Kev has left

  321. Ali Sabil

    thanks ! you too

  322. Ali Sabil

    I am off as well

  323. Ali Sabil

    so ttyl

  324. zooldk@gmail.com

    ?See ya later.. ciao!

  325. Ali Sabil has left

  326. zooldk@gmail.com has left

  327. Kev has joined

  328. Kev has left

  329. Kev has joined

  330. Kev has left

  331. Tobias has left

  332. Tobias has joined

  333. Kev has joined

  334. Neustradamus has left

  335. Neustradamus has joined

  336. Kev has left

  337. Kev has joined

  338. Neustradamus has left

  339. Neustradamus has joined

  340. Joe M has left

  341. luca tagliaferri has left

  342. Kev has left

  343. Tobias has left

  344. Tobias has joined

  345. Tobias has left