XMPP Council - 2012-08-15

  1. Tobias has left
  2. m&m has joined
  3. Neustradamus has left
  4. m&m has left
  5. Kev has joined
  6. stpeter has joined
  7. m&m has joined
  8. ralphm has joined
  9. m&m T - ~5 minutes
  10. stpeter 15?
  11. m&m /isgh
  12. m&m yesh
  13. stpeter you need last message correction!
  14. m&m I was testing you all
  15. m&m (-:
  16. stpeter a use case!
  17. stpeter I really really need to spend some quality time with XEP-0301 again
  18. m&m I think there needs to be a lock-down on 301 updates for a week or two
  19. stpeter heh
  20. ralphm i'm about to set up a filter
  21. stpeter 'tis time?
  22. ralphm indeed
  23. Kev It is.
  24. Kev 1) Roll call
  25. Kev MattJ sends apologies.
  26. ralphm here
  27. m&m absent
  28. m&m *presente
  29. ralphm it's getting old quickly now^Uhaha
  30. Kev Tobias: ?
  31. m&m It's just getting started
  32. Tobias yes.here
  33. m&m s/it's just getting started/indeed/
  34. Kev Right.
  35. Kev 2) Matt's IETF report.
  36. m&m so
  37. m&m 2.1) E2E — still progressing, mostly in JOSE not XMPP directly
  38. m&m by the way, if anyone is interested in a solution here, I would recommend joining the jose@ietf.org mailer and commenting on any non-OpenId use cases
  39. m&m 2.2) DNA — Stpeter and I wrote up a series of drafts for domain name associations (formerly assertions)
  40. m&m they are light on examples, and there is desire for more guidelines; which to do first, signaling preferences, etc
  41. m&m also includes prooftypes using DNSSEC/DANE and POSH
  42. stpeter POSH being "PKIX over Secure HTTP" -- basically parking your certificate at a well-known URI
  43. m&m thank you
  44. m&m 2.3) 6122bis — mostly waiting on PRECIS, but there are some changes to processing order, and what to do with certain classes of code points (e.g. full- and half-width)
  45. ralphm to be sure, this is the certificate proving that a host may act for a particular domain, right?
  46. m&m ralphm: yes, by virtue of HTTPS 30x redirects
  47. m&m request https://mydomain.com/.well-known/posh._xmpp-client._tcp.cer , get redirected to https://thathostingcomany.net/.well-known/posh._xmpp-client._tcp.cer
  48. m&m DNSSEC is our existing SRV lookups, but with the expectation the record(s) are signed (valid)
  49. Kev Oh, that's a bit icky isn't it?
  50. m&m Kev: it's not perfect, but it is deployable
  51. Kev Requiring people not just to know how to get to the final resource, but also to keep track of how HTTP panned out getting there, I mean.
  52. Kev Well-known-URIs are themselves icky, but I can hold my nose for that.
  53. m&m most HTTP libraries will let you know when a redirect is followed, and how
  54. Kev Does this allow more than one jump?
  55. m&m that right now is not specified … it could, and we'll probably need to put some limits around it
  56. Kev I've got a feeling of general unease about redirects and proofs, because you need to keep track of cert trust at each hop and blah.
  57. ralphm indeed. There have been issues with this in other protocols
  58. m&m Kev: alternate suggestions welcome
  59. Kev Not that this is a deal-breaker, I just enter it with trepidation.
  60. m&m so do most of us
  61. m&m but
  62. m&m it's at least something that could get implemented and deployed before universal IPv6
  63. stpeter well, universal DNSSEC
  64. stpeter (and DANE)
  65. Kev xmpp:jabber.org has IPv6.
  66. m&m I assert that universal DNSSEC will happen just after universal IPv6
  67. Kev Anyone using HE can't route to it...
  68. m&m Kev: that's not universal
  69. m&m d-:
  70. m&m POSH is one possible approach, DNSSEC/DANE is another
  71. m&m both have the potential to make dialback even more relevant than before
  72. Kev OK. I need to use my time machine to create some more time to look at this better.
  73. m&m Kev: I know exactly what you mean (-:
  74. Kev Was that the IETF report done with?
  75. ralphm Kev: go back further and tell those IPv4 people to do it right
  76. Kev ralphm: I think the IPv4 people /did/ do it right.
  77. Kev IPv6 is much more contentious.
  78. m&m re IETF report — there's probably some things happening in PRECIS that are relevant to us also
  79. m&m oh!
  80. ralphm Kev: point
  81. m&m finds link
  82. m&m http://tools.ietf.org/html/draft-marques-l3vpn-end-system-06
  83. m&m this is a draft for using XMPP pubsub for propagating layer-3 VPN information
  84. ralphm +1
  85. Kev Oh, neato.
  86. m&m well, it's a lot of things, but XMPP is in there
  87. m&m they do need some help, though
  88. Kev Maybe this XMPP lark will take off.
  89. m&m HTTP(s) is the One True Protocol™
  90. m&m anyway, I would recommend those enthusiastic about pubsub to read that draft ...
  91. ralphm oh collection nodes
  92. m&m … and contact Pedro Marques <roque@contrailsystems.com> with corrections, suggestions, questions, etc
  93. m&m ralphm: yeah, although I don't think they actually need them for what they are doing
  94. ralphm m&m: pretty unlikely
  95. m&m Also, anyone interested in end-to-end encryption and signing should pay attention to JOSE
  96. m&m and that is all
  97. Kev Perhaps if I didn't lose the best part of a day to dealing with DDoS attacks I'd have time for this.
  98. Kev *grumble*
  99. Kev OK, thanks Matt.
  100. stpeter yeah
  101. Kev 3) Date of next meeting.
  102. m&m SBTSBC WFM
  103. Kev We'll have 308's LC ended by next Wednesday, so we should have something to discuss...
  104. m&m /nod
  105. Kev SBTSBC works for me, I think.
  106. Tobias WFM
  107. ralphm +1
  108. Kev Great.
  109. Kev 4) Any other business?
  110. m&m not for me
  111. Kev OK, we're done then.
  112. Kev Thanks all
  113. Kev bangs the gavel.
  114. stpeter yes, thanks
  115. m&m gracias
  116. ralphm thanks!
  117. m&m has left
  118. m&m has joined
  119. ralphm has left
  120. m&m has left