XMPP Council - 2012-05-09

  1. Tobias has left
  2. Tobias has joined
  3. Tobias has left
  4. Tobias has joined
  5. Tobias has joined
  6. Tobias has joined
  7. linuxwolf has joined
  8. MattJ has joined
  9. Kev ~1 hour.
  10. stpeter has joined
  11. ralphm has joined
  12. linuxwolf ~5 min
  13. stpeter waves
  14. Tobias hi
  15. Kev It is time.
  16. Kev 1) Roll call
  17. Kev I be here.
  18. linuxwolf presente
  19. ralphm tadaaah
  20. Tobias /me2
  21. Kev MattJ: Ping.
  22. MattJ Pong
  23. MattJ Present
  24. Kev http://xmpp.org/extensions/diff/api/xep/0068/diff/1.1/vs/1.2rc2
  25. Kev 2) http://xmpp.org/extensions/diff/api/xep/0068/diff/1.1/vs/1.2rc2 Accept 1.2
  26. Kev Rather.
  27. linuxwolf +1
  28. MattJ +1
  29. Tobias +1
  30. Kev I'm almost +1.
  31. Kev The example for a new field name seems to be sane.
  32. Kev <field var="x-{http://example.com/pubsub}time_restrictions" type="text-multi" label="Limit to these time ranges">
  33. Kev That seems reasonable.
  34. stpeter looks
  35. Kev But AFAICS from the diff, we're just removing an obligation on people making new values to put x- on them, and I think we should encourage them to namespace themsomehow as bove, instead.
  36. Kev Of course, my paste has the strikout x- as well as the added namespaceish stuff, which doesn't paste into here.
  37. ralphm hehe
  38. stpeter you're talking about http://xmpp.org/extensions/tmp/xep-0068-1.2.html#example-2
  39. Kev I am.
  40. Kev The example seems entirely sane - I'm suggesting we include text to match.
  41. linuxwolf Kev: There's also section 3.3, with SHOULDs (not MUSTs) around what the naming conventions
  42. Kev (Or you tell me there is text to match and I can't see it)
  43. Kev linuxwolf: 3.4, don't you mean?
  44. linuxwolf d'oh
  45. linuxwolf yeah
  46. linuxwolf and it's not enough
  47. linuxwolf maybe
  48. stpeter I'd be fine with recommending Clark notation
  49. stpeter all that 3.4 says is "If the FORM_TYPE is not registered, the field MAY have any name (managed by the namespace owner)."
  50. Kev Right.
  51. stpeter which admittedly is rather weak :)
  52. Kev I think we should namespace it somehow.
  53. linuxwolf I'm still +1 to the current, but would not object to further specificity
  54. Kev Clark notation, as in the example, seems right to me.
  55. Kev Or sensible, at least, I'm not opposed to other sensible options.
  56. linuxwolf We're XML, so Clark notation seems the best fit, IMO
  57. ralphm agreed
  58. ralphm I'm not sure if that need to be a MUST
  59. ralphm but clearly we should at least strongly recommend that custom fields do this
  60. linuxwolf however, I don't want everyone that followed XEP-68 < 1.2 to feel obligated to change their code
  61. Kev I'm happy with MUST be clearly namespaced, SHOULD use Clark notation, legacy implementations MAY use the obsolete x- notation.
  62. Kev Would that suit everyone else?
  63. ralphm I'd be in favor of MUSTing the notation
  64. Tobias fine with me
  65. linuxwolf I think so
  66. stpeter Kev: this is for forms where the FORM_TYPE is registered with the XSF, or also for forms where the FORM_TYPE is unregistered?
  67. Kev ralphm: I'm not opposed to MUST use Clark *except* existing x- implementations.
  68. linuxwolf stpeter: both, no?
  69. Kev stpeter: I think for all forms, because I can non-XSF a form and you can extend it non-XSF.
  70. stpeter Section 3.4 is a bit ambiguous about naming in the context of forms where the FORM_TYPE is registered
  71. stpeter I think we kind of assume that the field "namespace" is inherited from the FORM_TYPE
  72. ralphm stpeter: that
  73. Kev I'm happy with text along the lines of 'extending forms outside your namespace requires...'.
  74. linuxwolf that
  75. Kev I think that's the critical thing. If it's not your form, you have to namespace your changes.
  76. stpeter so why have a FORM_TYPE of "http://example.com/foo" and then field names of {http://example.com/foo}bar" ?
  77. ralphm it is rather unfortunate that we also have these pubsub# and muc# prefixes, but yeah, leaving off {...} assumes the form namespace
  78. Kev stpeter: See above :)
  79. stpeter ralphm: indeed -- I have no idea why we thought that was a good idea :)
  80. stpeter Kev: ok, yes
  81. ralphm so must use clark except for legacy apps using x-
  82. stpeter right
  83. ralphm +1 then
  84. stpeter I will formulate some text and then run it by the list
  85. Kev I suggest that instead of pre-approving rc3, we discuss again next week/week after.
  86. Kev Just because we've discussed a number of approaches and the possibility for miscommunication is high.
  87. stpeter not quite up for wordsmithing the text here :)
  88. stpeter WFM
  89. stpeter right
  90. stpeter agreed
  91. Kev So I think we're done with this.
  92. Kev 3) Date of next meeting.
  93. Tobias yup
  94. Kev I don't believe I can make next week at the normal time.
  95. ralphm +1W
  96. Kev You folks could go on without me, or we can reschedule, or miss a week.
  97. ralphm given the amount of work, skipping a week seems fine
  98. Kev Anyone else?
  99. MattJ wfm
  100. Tobias wfm
  101. MattJ is ~50% here
  102. linuxwolf I'm ambivalent (-:
  103. Kev linuxwolf: ambivalent, or disinterested?
  104. ralphm linuxwolf: we can still hang out here next week
  105. Kev Anyway, a fortnight now seems vaguely agreed.
  106. Kev 4) Any other business?
  107. linuxwolf ralphm: (-:
  108. linuxwolf no other business
  109. Kev Right, I think we're done.
  110. Kev Thanks all.
  111. Kev bangs the gavel.
  112. Tobias thanks
  113. stpeter ok
  114. stpeter I've provisionally updated 68
  115. stpeter http://xmpp.org/extensions/tmp/xep-0068-1.2.html#approach-fieldnames
  116. stpeter I need to heaad into the office, bbiab
  117. stpeter I'll post to standards@ about the x- changes
  118. Kev Thanks.
  119. ralphm stpeter: I think we should mention that {http://jabber.org/protocol/pubsub#subscribe_authorization}pubsub#subscriber_jid is equivalent to pubsub#subscriber_jid
  120. ralphm also, example 168 of XEP-0060 has a typo for that field name
  121. ralphm and example 2 in your draft of 0068 has an incorrect FORM_TYPE
  122. ralphm (i.e. it lacks the #subscribe_authorization part)
  123. stpeter ok, will check those when I get to the office, gotta run!
  124. stpeter has left
  125. linuxwolf has left
  126. Tobias has left