XSF logo 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