XSF Discussion - 2010-05-15

  1. zooldk@gmail.com

    Hey All

  2. Ali Sabil

    hey Steffen

  3. zooldk@gmail.com

    hola Ali :-)

  4. zooldk@gmail.com


  5. zooldk@gmail.com

    we have three XEPs that needs to be review

  6. 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)

  7. Ali Sabil


  8. Joe M


  9. zooldk@gmail.com

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

  10. zooldk@gmail.com

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

  11. Joe M

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

  12. Ali Sabil

    same here

  13. Joe M

    were you part of the 45 MUC review?

  14. zooldk@gmail.com

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

  15. zooldk@gmail.com

    nope.. sorry

  16. Joe M

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

  17. zooldk@gmail.com

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

  18. Joe M

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

  19. 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

  20. Ali Sabil

    that wouldn't be a bad idea

  21. Joe M


  22. zooldk@gmail.com

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

  23. Ali Sabil


  24. zooldk@gmail.com


  25. Joe M

    please continue while i catch up

  26. zooldk@gmail.com

    ha ha ;-)

  27. Joe M


  28. zooldk@gmail.com

    give me 1 min to get the coffee

  29. zooldk@gmail.com


  30. zooldk@gmail.com

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

  31. zooldk@gmail.com

    but there are some stuff that could be more explicit

  32. Ali Sabil

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

  33. 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

  34. 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 ?

  35. zooldk@gmail.com

    the hash?

  36. Ali Sabil

    yes the hash

  37. zooldk@gmail.com

    hmm let me read

  38. zooldk@gmail.com

    heh yeah your riight. makes sense

  39. Ali Sabil

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

  40. zooldk@gmail.com

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

  41. zooldk@gmail.com


  42. Ali Sabil

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

  43. zooldk@gmail.com

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

  44. zooldk@gmail.com

    but its good to be explicit anyways

  45. zooldk@gmail.com

    the same thing with the size of the file

  46. Ali Sabil

    let me read

  47. Ali Sabil

    yes, I agree

  48. zooldk@gmail.com

    there stands nothing about the unit right?

  49. Ali Sabil

    I can't find anything

  50. zooldk@gmail.com

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

  51. Joe M

    how many clients out there implement socks5 bytestreams? any idea

  52. Joe M


  53. zooldk@gmail.com

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

  54. zooldk@gmail.com

    is there anyone?

  55. zooldk@gmail.com

    most uses the old file transfer as well, right?

  56. Joe M

    out of band

  57. Joe M

    that's the only one i've seen implemented

  58. Ali Sabil

    you mean xep-065 ?

  59. Joe M

    yes, 65

  60. Ali Sabil

    I think Gajim implements it

  61. Joe M


  62. Joe M


  63. zooldk@gmail.com

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

  64. Ali Sabil

    that would be great actually

  65. zooldk@gmail.com

    to see real life examples and find them easierly

  66. 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

  67. Joe M

    Looks like you'd have to start again

  68. Joe M

    but this is for relatively small files, no?

  69. zooldk@gmail.com

    normally.. ;-)

  70. zooldk@gmail.com

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

  71. zooldk@gmail.com

    there are more effective ways there..

  72. Joe M


  73. Joe M

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

  74. Joe M

    Am I off or is that the basic jist?

  75. zooldk@gmail.com


  76. Joe M

    so the file goes peer to peer

  77. Ali Sabil

    socks5 is used as a transport

  78. Joe M


  79. zooldk@gmail.com

    like a normal jingle

  80. Joe M


  81. zooldk@gmail.com

    its just used to set up a stream

  82. Ali Sabil

    concerning the resume transfer issue

  83. Joe M

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

  84. Joe M

    sorry Ali...

  85. Ali Sabil

    imagine a fictionnal bitorrent transport

  86. Joe M


  87. Joe M

    we can talk about resume

  88. Ali Sabil

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

  89. zooldk@gmail.com

    yes.. your proabably right

  90. Joe M

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

  91. 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

  92. Joe M


  93. Ali Sabil

    am I wrong ?

  94. zooldk@gmail.com

    no that would probably be the easiest

  95. Joe M

    what you are saying makes sense to me

  96. Ali Sabil

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

  97. Joe M

    i don't know enough about the transports to comment

  98. zooldk@gmail.com

    have you seen any clients doing it?..

  99. Ali Sabil

    resuming filetransfers ?

  100. zooldk@gmail.com


  101. zooldk@gmail.com

    I mean xmpp clients.. not ftp and others

  102. zooldk@gmail.com

    adium and pidgin doesnøt

  103. zooldk@gmail.com


  104. Ali Sabil

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

  105. Ali Sabil

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

  106. zooldk@gmail.com

    ok.. lets leave it there then

  107. Joe M

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

  108. Joe M

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

  109. zooldk@gmail.com

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

  110. Joe M

    would enable the extension of the server to inspect, etc

  111. zooldk@gmail.com


  112. Joe M

    should these three xeps but collapsed in to 1?

  113. Joe M

    they are very short and so closely related

  114. zooldk@gmail.com

    i dont think so

  115. Joe M


  116. Ali Sabil

    I don't think so

  117. zooldk@gmail.com

    event though they are related :-)

  118. Joe M

    fair enough

  119. Ali Sabil

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

  120. Joe M


  121. zooldk@gmail.com

    its like 166, 167 etc.

  122. zooldk@gmail.com

    they were together in the start but was split up

  123. zooldk@gmail.com

    to keep it simple

  124. Joe M

    that's good to know, thx

  125. zooldk@gmail.com


  126. Ali Sabil

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

  127. zooldk@gmail.com


  128. zooldk@gmail.com

    167 descripes the payloads as far as I remember

  129. Ali Sabil

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

  130. Joe M


  131. Joe M

    I'm wondering about the communicating to of the hash

  132. Joe M

    it says it can be done at any time

  133. Joe M

    does that present a challenge for someone implementing?

  134. zooldk@gmail.com

    while the session is open

  135. Joe M

    and ensure interop?

  136. zooldk@gmail.com

    have to see 96

  137. Joe M


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

  139. zooldk@gmail.com

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

  140. Ali Sabil

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

  141. zooldk@gmail.com

    yes I see the import

  142. zooldk@gmail.com

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

  143. zooldk@gmail.com

    I mean 96 will dissapear

  144. Ali Sabil

    I don't know these things are generally managed

  145. zooldk@gmail.com

    hmmm I was just wondering

  146. Ali Sabil

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

  147. zooldk@gmail.com

    well I dunno..

  148. zooldk@gmail.com

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

  149. zooldk@gmail.com

    its in Draft..

  150. 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?

  151. Ali Sabil

    that's what the intro seems to imply

  152. zooldk@gmail.com

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

  153. zooldk@gmail.com

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

  154. zooldk@gmail.com

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

  155. Ali Sabil

    can we make a small summary before moving on ?

  156. zooldk@gmail.com


  157. Joe M


  158. zooldk@gmail.com

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

  159. zooldk@gmail.com

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

  160. Ali Sabil

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

  161. Joe M


  162. zooldk@gmail.com


  163. Ali Sabil

    is it a MUST transfer ?

  164. Joe M

    good question

  165. Ali Sabil

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

  166. zooldk@gmail.com

    have to be MUST

  167. zooldk@gmail.com

    SHOULD is an option

  168. Joe M

    and MD5 only?

  169. Ali Sabil

    is the hash a requirement ?

  170. Joe M

    a great question

  171. zooldk@gmail.com

    I dont think so

  172. Ali Sabil

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

  173. zooldk@gmail.com

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

  174. zooldk@gmail.com

    the magic word is "can".

  175. zooldk@gmail.com

    so i think it is optional

  176. Ali Sabil

    so let's turn this into a SHOULD

  177. Joe M

    makes sense

  178. zooldk@gmail.com

    where should we put the unit of bytes?

  179. zooldk@gmail.com

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

  180. Ali Sabil


  181. Ali Sabil

    hmm seems like xep-0096 had support for resuming transfers

  182. zooldk@gmail.com

    he he he

  183. Joe M

    where in 96?

  184. Ali Sabil


  185. zooldk@gmail.com

    where do you see it

  186. Joe M


  187. zooldk@gmail.com

    so its made in the setup protocol there

  188. Ali Sabil


  189. zooldk@gmail.com

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

  190. Ali Sabil

    it doesn't seem to be

  191. zooldk@gmail.com


  192. Joe M

    that's an issue

  193. Ali Sabil

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

  194. zooldk@gmail.com


  195. zooldk@gmail.com


  196. Joe M

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

  197. Joe M

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

  198. Joe M

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

  199. zooldk@gmail.com

    to reuse 0047

  200. zooldk@gmail.com

    no they would probably go for the inband

  201. Joe M

    again, i'm thinking interop

  202. Joe M

    0047 is to be deprecated in favor of 261?

  203. zooldk@gmail.com

    seems like it

  204. zooldk@gmail.com

    same words used as in 234

  205. Joe M

    ok, so are we on to 260?

  206. Ali Sabil

    what do you think about this summary:

  207. 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

  208. Ali Sabil

    (indentations seems to have been lost)

  209. Joe M

    i can see it pretty well

  210. Joe M

    using Adium

  211. Ali Sabil

    oh, not me

  212. zooldk@gmail.com

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

  213. zooldk@gmail.com

    I see it as well (adium) :-)

  214. Ali Sabil

    Should use explicit XSD in 0234 (avoid imports) ?

  215. zooldk@gmail.com

    yes.. Well at least I think so

  216. Joe M


  217. zooldk@gmail.com

    otherwise we seem to have a good summary

  218. zooldk@gmail.com

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

  219. Ali Sabil

    no idea, I am new here :)

  220. Joe M

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

  221. Joe M

    I think we're all new :)

  222. zooldk@gmail.com

    only been here half a year.. so me too

  223. Ali Sabil

    I'd say we post to the mailing list

  224. zooldk@gmail.com

    sorry.. my network just blow up

  225. Ali Sabil

    Welcome back

  226. zooldk@gmail.com

    ha ha.. thanks

  227. zooldk@gmail.com

    yeah.. lets send it to the techlist

  228. zooldk@gmail.com

    shal I summarize it in a mail?

  229. zooldk@gmail.com


  230. Joe M

    great, yes

  231. Ali Sabil


  232. zooldk@gmail.com

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

  233. Joe M

    Thank you!

  234. zooldk@gmail.com

    we have nothing more to the 260,261?

  235. Ali Sabil

    perfect, thanks

  236. zooldk@gmail.com


  237. Joe M

    we probably do, I have 15 more minutes

  238. zooldk@gmail.com

    me too.. going to a dinner soon

  239. Ali Sabil

    hmm, I haven't started reviewing 260 nor 261

  240. zooldk@gmail.com

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

  241. Ali Sabil

    but I have a problem with <proxy-error>

  242. Ali Sabil

    in 260

  243. Ali Sabil

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

  244. zooldk@gmail.com

    ahh ok

  245. Joe M

    tomorrow is difficult for me as well

  246. Joe M

    what is the issue w/proxy-error?

  247. Ali Sabil

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

  248. Ali Sabil

    in case you sent multiple proxy candidates ?

  249. Joe M

    ah, i see it's too generic

  250. Joe M

    do we want the protocol to tell us?

  251. Ali Sabil

    <candidate-used> has cid

  252. zooldk@gmail.com

    isn't it hanging on a candidate?

  253. Ali Sabil

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

  254. Ali Sabil

    yep I see

  255. zooldk@gmail.com

    and proxy when only one of them?

  256. Joe M

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

  257. Ali Sabil

    yes that's right

  258. Ali Sabil

    I got it wrong

  259. Ali Sabil


  260. Joe M


  261. Ali Sabil

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

  262. Joe M

    good idea

  263. Ali Sabil

    because in 15 minutes we won't get much done

  264. Joe M


  265. zooldk@gmail.com


  266. zooldk@gmail.com

    how about wedensday?

  267. zooldk@gmail.com

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

  268. zooldk@gmail.com

    or are you too busy Joe?

  269. zooldk@gmail.com

    we can make it later if you want

  270. Joe M

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

  271. zooldk@gmail.com

    ha ha

  272. Joe M

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

  273. Joe M


  274. Ali Sabil


  275. Joe M

    one week from today could work

  276. Joe M

    or very early in the AM New York time

  277. zooldk@gmail.com

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

  278. Ali Sabil

    next saturday ?

  279. Joe M

    i wish!!

  280. Joe M

    Swiss banks are a little fussy about security ;)

  281. Ali Sabil

    use BOSH

  282. zooldk@gmail.com

    wait.. I'll check my calendar

  283. zooldk@gmail.com

    yeah.. use BOSH

  284. Joe M

    I'll check out a BOSH client

  285. zooldk@gmail.com

    I made several my self.. easy wth Strophe

  286. Joe M


  287. zooldk@gmail.com

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

  288. Joe M

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

  289. zooldk@gmail.com

    ok Joe, its up to you

  290. Ali Sabil

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

  291. zooldk@gmail.com


  292. zooldk@gmail.com


  293. Joe M


  294. Ali Sabil

    both Steffen and me are on the CEST timezone

  295. Joe M


  296. Joe M

    i'm think next Saturday, but a bit earlier

  297. zooldk@gmail.com

    yeah.. Denmark and Norway right?

  298. Joe M


  299. Ali Sabil

    yes :)

  300. Joe M

    good spots in the world

  301. zooldk@gmail.com

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

  302. Joe M

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

  303. Joe M

    Thanks for your time.

  304. zooldk@gmail.com

    yes.. just pass a mail around!

  305. Ali Sabil

    thanks everyone

  306. zooldk@gmail.com


  307. zooldk@gmail.com

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

  308. Ali Sabil


  309. Joe M

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

  310. Ali Sabil

    thanks ! you too

  311. Ali Sabil

    I am off as well

  312. Ali Sabil

    so ttyl

  313. zooldk@gmail.com

    ?See ya later.. ciao!