XSF Discussion - 2018-03-28


  1. jonasw

    moparisthebest, I’m pretty sure that that’s not true. if only on the grounds that small parts would lack the Schöpfungshöhe (that’s the german term, sorry I don’t know the proper english one) to even be copyrightable.

  2. jonasw

    like, some constants which are irrelevant to the working of the protocol and are merely there to establish compatbility

  3. Zash

    jonasw: The being-enough-work-ines?

  4. jonasw

    Zash, yeah, kinda

  5. jonasw

    like, I could probably not claim copyright on a poem like: Foo, the bar, frobnitzed the dingus.

  6. jonasw

    for certain definitions of poem

  7. jonasw

    then again, that might be dadaistic enough to work, but whatevre.

  8. Zash

    "Verkshöjd"

  9. jonasw

    is that a composed word of some kind? I get "verk", but I can’t interpret "shöjd"

  10. Zash

    Work-height basically

  11. jonasw

    ah, that makes sense

  12. jonasw

    so verks-höjd

  13. Zash

    Yeah

  14. jonasw

    yeah, schöpfungs-höhe is creation-height

  15. pep.

    https://www.fastcompany.com/40547684/slack-picked-a-weird-time-to-make-it-easier-for-bosses-to-download-your-private-chats

  16. flow

    I believe that the idea to distribute the persistent groupchat archives over multiple servers by having the participant's server also hosting a copy of the channel archive is a desirable. But Georg got me thinking. It would be great if the participant's service could re-use the stanza-id's from the MIX channel in it's own archive for the user. That would be a great advantage in multiple aspects. We could possibly achieve this by moving the participant's copy of the MIX channel archive into a PEP node with the channel's JID as node name. Thoughts?

  17. flow

    I believe that the idea to distribute the persistent groupchat archives over multiple servers by having the participant's server also hosting a copy of the channel archive is desirable. But Georg got me thinking. It would be great if the participant's service could re-use the stanza-id's from the MIX channel in it's own archive for the user. That would be a great advantage in multiple aspects. We could possibly achieve this by moving the participant's copy of the MIX channel archive into a PEP node with the channel's JID as node name. Thoughts?

  18. flow failed using poezio's LMC…

  19. jonasw

    what

  20. jonasw

    what would the advantages be?

  21. Ge0rG

    everybody would see which MUCs you are in!

  22. Syndace

    There we go! I'm exited to announce the release of my python-omemo implementation, which can be found on https://github.com/Syndace/python-omemo! I'll try to be in the jdev@ and xsf@ mucs as much as possible to answer questions and fix bugs in the next weeks and I really hope this release will help OMEMO to improve.

  23. MattJ

    Syndace, great news :) You should send an [ANN] to the jdev mailing list as well, for the client developers who are not in the MUCs

  24. MattJ

    (if you haven't already)

  25. rion

    Syndace: does gajim use it already?

  26. Syndace

    rion: no, it was private until five minutes ago ^^

  27. rion

    =)

  28. Zash

    For each client written in python, ask "Does {client} use it already?"

  29. rion

    One day I'll make a plugin for Psi to load python extensions =)

  30. Kev

    I did that with the original plugin implementation about 13 years ago, I think :)

  31. rion

    and javascript

  32. Zash

    Better avoid Lua tho, wouldn't wanna touch a language specifically designed for embedding. :)

  33. MattJ

    Save that for writing servers

  34. ralphm

    Kev: I might have missed it, but is there a writeup for the so-called "xmpp2 routing" stuff discussed at FOSDEM?

  35. ralphm

    (or really, the Summit)

  36. Ge0rG

    ralphm: https://wiki.xmpp.org/web/XMPP_2.0 is probably the best resource, but pre-summit

  37. Ge0rG

    ralphm: also https://op-co.de/tmp/whats-wrong-with-xmpp-2017.pdf

  38. Kev

    ralphm: I think JC sent out minutes from the summit.

  39. Kev

    https://wiki.xmpp.org/web/Minutes_of_the_2018_Summit:_Day_one#1.1._Message_Routing

  40. ralphm

    Thanks. It seems that the examples in the XMPP_2.0 wiki page are more fleshed out, but maybe we should have an actual XEP on this. I hear this being talked about a lot, but now having people implementing it (here) this is still a bit vague.

  41. MattJ

    ralphm, who is implementing it? I think it's a bit too early and vague for that...

  42. MattJ

    It has multiple unresolved issues

  43. MattJ

    "xmpp 2.0" is more a direction than a protocol

  44. Zash

    The direction started by Carbons and MAM, prompted by mobile clients and "all messages on all devices" thing?

  45. MattJ

    Zash, I guess. But regardless of that, I don't think there is any denying that the proposed changes simplify a lot of things

  46. ralphm

    MattJ: my own team

  47. ralphm

    MattJ: and I'm talking about MIX, not XMPP 2.0.

  48. ralphm

    MattJ: however, part of MIX in its current form is a dependency on things handled by the participant's local server (roster integration, PAM).

  49. ralphm

    I'm also unsure how it works if a client only wants to receive notifications for a subset of the pubsub nodes subscribed to by the bare JID when joining the room.

  50. flow

    Syndace, +1

  51. ralphm

    Or is that not a usecase that is covered by MIX?

  52. Zash

    Pretty sure that was part of the whole MIX design. Possibly handled by the pubsub-account stuff?

  53. ralphm

    Well, I can see that you can specify which pubsub nodes you want to subscribe to when joining a channel, I don't see how you can differentiate between different resources.

  54. ralphm

    (or whether this is actually a desirable feature)

  55. Kev

    ralphm: I can write up a 'new IM routing rules' XEP, at least an early version, it's on my TODO (along with quite a depressing amount of spec work, actually).

  56. ralphm

    Kev: cool. Does it correspond with that wiki page that Ge0rG linked, or is it different from that?

  57. Kev

    As for selective filtering of pubsub notifications I think that's a thing that is outside MIX or routing-NG.

  58. Zash

    Daves PAM?

  59. Kev

    I'm using "XMPP 2" to talk about how all these moving parts fit together sensibly, FWIW. It's too easy to change one bit in isolation and end up with a patchwork that doesn't do what's needed (see interactions between Carbons and MAM, for example).

  60. ralphm

    Kev: ok, but I'm still curious how it works, because now you're subscribed with the bare JID, you can't use CAPS filtering

  61. Kev

    Zash: It's PAMish, yes.

  62. Kev

    ralphm: You can, it's just a different you.

  63. ralphm

    Kev: what do you mean?

  64. Zash

    Bunneh: xep pam

  65. Bunneh

    Zash: Pubsub Account Management (Standards Track, Deferred, 2017-09-11) See: https://xmpp.org/extensions/xep-0376.html

  66. Kev

    ralphm: I mean that PAM is going to do filtering on the recipient side, when some clients aren't interested in some stuff to which a different client subscribed.

  67. Kev

    I think this actually goes far beyond pubsub, though.

  68. ralphm

    But I thought you said that with XMPP 2 routing you wouldn't need PAM?

  69. Kev

    You don't need some aspects of PAM, yea, but you still need something somewhere doing something.

  70. Kev

    Take the example people keep giving of not wanting a 5000-user MUC sending messages to your phone unless you're actively viewing it at the moment.

  71. Kev

    Which goes beyond selective filtering of pubsub notifications.

  72. Kev

    But does tie into the push and highlighting rules.

  73. Kev

    I did put some thoughts into https://github.com/Kev/xeps/blob/58153226d6caf93fbb2b4d3fbd9819e814942e37/inbox/multi-client.xml before the Summit, with the aim of getting it published as a rough overview of how everything comes together in xmpp 2.

  74. Kev

    Perhaps I should tidy it up a bit and get it submitted so we can have something outside the wiki.

  75. ralphm

    That'd be great

  76. Kev

    I'm going to make activation of IM-NG an iq after bind, on the basis that it can then be wrapped up inside bind2.

  77. ralphm

    interesting

  78. Ge0rG

    how do you wrap an IQ into bind2?

  79. Kev

    Ge0rG: TBD.

  80. Kev

    But in principle by saying "also activate these things please".

  81. Ge0rG

    I'm not quite convinced.

  82. MattJ

    daniel, is it the case that if an oob payload is in a message, Conversations only shows the attachment if <body> == URL?

  83. daniel

    Either body == oob

  84. daniel

    Or just oob set and no body

  85. MattJ

    Does it use <desc>?

  86. daniel

    The first one is the one I usually expect. The later is only a bonus if you will

  87. daniel

    No

  88. daniel

    i can make it use desc on the sending side if you want me to

  89. MattJ

    Trying to figure out how I can send an image with a piece of text that works in clients whether they support oob or not

  90. MattJ

    e.g. I could do: <body>[some description]: [some url]</body> along with the oob payload

  91. MattJ

    But then Conversations wouldn't handle it the "nice way" (and I have no idea about other clients)

  92. moparisthebest

    what if you just send the image, followed by the description, in 2 different messages?

  93. MattJ

    as you raised on the mailing list, I think this is partly an issue with XEP-0066 being used differently to how it was originally intended, so the XEP doesn't help clarify things

  94. Zash

    moparisthebest: you could, but it'd be ... not nice.

  95. MattJ

    moparisthebest, not ideal, but I considered it

  96. MattJ

    it's really more supposed to be like a caption for the image/file

  97. MattJ

    or a title, or something

  98. MattJ

    Imagine I sent multiple in a row. It wouldn't be clear if the text applied to the one above or the one below

  99. moparisthebest

    might just be the only thing that works well across everything *today*, come up with something better for the future :)

  100. Zash

    `body := url \n desc` would have been nice

  101. daniel

    don‘t let that stop you from coming up with something 'nice' but don’t expect Conversations to handle image and text in the same message any time soon

  102. MattJ

    daniel, is that just because of UI limitations?

  103. daniel

    the internal db is way too messed up for that

  104. MattJ

    Ok

  105. daniel

    and UI

  106. daniel

    but that's more 'solveable' than the db

  107. moparisthebest

    MattJ, yea I hit that problem with websites all the time, I'd think people would be used to it (if the first thing is an image, then description follows, if first thing is a description, then image follows)

  108. MattJ

    moparisthebest, except in an IM conversation, the first thing will generally always be text :)

  109. MattJ

    Maybe we should specify a new XEP for <hr> over XMPP

  110. moparisthebest

    then send the text first :)

  111. MattJ

    <message><body>----------------</body><hr xmlns="urn:xmpp:hr:0"/></message>

  112. moparisthebest

    me doing something:

  113. moparisthebest

    <image here>

  114. Kev

    MattJ: FWIW, we're currently starting to support this through references.

  115. MattJ

    Kev, "we"? Swift? XMPP?

  116. Kev

    Swift.

  117. Kev

    Initially dealing with images, then looking at other things.

  118. MattJ

    XEP number..?

  119. Kev

    (FDP next, which is probably of limited interest to lots of people, but important for us)

  120. MattJ

    "references doesn't find anything on /extensions/)

  121. Zash

    Kev: Does this include nice ways for bots to attach special annotations?

  122. MattJ

    "references" doesn't find anything on /extensions/)

  123. Zash

    -xep references

  124. Bunneh

    Zash: References (Standards Track, Deferred, 2017-09-11) See: https://xmpp.org/extensions/xep-0372.html

  125. Kev

    372, although Edwin's about to do an update with more useful stuff like mime types etc.

  126. Kev

    Zash: Yes.

  127. MattJ

    Oh, deferred

  128. Ge0rG

    I fear a bit that 372 is the MIX of message references.

  129. MattJ

    Ok, so now I have 4 ways to communicate images to clients? :)

  130. MattJ

    <body>, <html>, <x oob> and <reference>

  131. MattJ

    and then should be able to support every client

  132. Zash

    -xep message attaching

  133. Bunneh

    Zash: Message Attaching (Standards Track, Deferred, 2017-09-11) See: https://xmpp.org/extensions/xep-0367.html

  134. MattJ

    except Conversations won't show the image even though it could

  135. MattJ

    Can we just pick one?

  136. daniel

    I'll probably support Sims at some point

  137. MattJ

    5

  138. daniel

    Or references. What ever the best practices will be

  139. daniel

    I thought Sims = references

  140. Kev

    Kinda.

  141. Kev

    Sims binds a transfer mechanism on top of references.

  142. Kev

    So it's a Reference with additional information on how to start a file transfer to get it.

  143. Ge0rG

    I thought Sims binds a green crystal on top of avatar heads.

  144. Kev

    I think we need to move towards References so we can do things like @mentions and the like sensibly.

  145. Zash

    -xkcd 927

  146. Bunneh

    https://imgs.xkcd.com/comics/standards.png

    Standards
    Standards
  147. daniel

    Kev: how would you attach an image with a reference w/o using Sims?

  148. Ge0rG

    daniel: http upload URI?

  149. Kev

    Define 'attach'.

  150. Ge0rG

    Kev: what about E2EE?

  151. MattJ

    Kev, so to get Swift to do what I want, I should follow XEP-372 or XEP-0385?

  152. Kev

    It's a reference to a URI, so you provide the image somehow (e.g. HTTP Upload) and then reference it.

  153. daniel

    I thought that's what Sims was

  154. daniel

    Only more specific to media

  155. daniel

    Whereas references are generic

  156. Kev

    MattJ: What exactly was it you wanted?

  157. Kev

    daniel: References are fairly generic, and Sims uses References.

  158. MattJ

    Send an image with attached text, or text with attached image, whichever way you want to view it

  159. MattJ

    oob url + desc does what I want already, except it's lacking client support

  160. Kev

    The image also needs to be transferred? Or that exists already?

  161. MattJ

    I have a URL for it

  162. Kev

    372 it.

  163. Kev

    I expect this to be on trunk in the next couple of days in an early state (receiving, anyway, how to do this sending sensibly is a much harder question).

  164. MattJ

    372 feels strange for image attachment

  165. MattJ

    Looks like it wants a character range

  166. MattJ

    Which in my case is easily done - the entire message

  167. jonasw

    whereas "character" is not properly defined.

  168. MattJ

    But if I only set the range to half the message, what would it show?

  169. Kev

    In the case of image URIs, Swift's not going to do much of anything with the range, and you could elide either the range or the URI in the body ok.

  170. Ge0rG

    Also should it hide the referenced text? use it as an alt tag?

  171. Ge0rG

    We need to have the URI in the body for legacy clients.

  172. Kev

    It's more interesting when you've got something like @MattJ and you want to link that to the appropriate user in the UI.

  173. MattJ

    Sure, I understand it for that use-case

  174. MattJ

    For my current one however, it feels wrong

  175. Kev

    Just don't include a range :)

  176. jonasw

    I’d also like to have a range-less thing which uses SIMS syntax. kinda like OOB with more metadata.

  177. jonasw

    but how to handle cases when there /is/ a range

  178. MattJ

    Oh wait, it's optional, ok

  179. Tobias

    MattJ, what do you think about 385? But that probably shares similar problems as references. At least on the outer level.

  180. MattJ

    I don't know yet

  181. Kev

    https://github.com/xsf/xeps/pull/614 - very basic outline of XMPP 2 IM routing.

  182. Kev

    ralphm: ^

  183. Tobias

    daniel, but yeah, SIMS is basically references + metadata + source hints on how to get the data

  184. Ge0rG

    Kev: just in time for Council meeting?

  185. Kev

    And as we're putting metadata into 372 imminently, I guess 385 will move to be References source hints.

  186. Tobias

    daniel, but i think there are plans to shove metadata into references

  187. Kev

    And as we're putting metadata into 372 imminently, I guess 385 will move to be References + source hints.

  188. Tobias

    Kev, nah..you can shove the source hints into references too

  189. Tobias

    Kev, i guess you could also force a thumbnail into references somehow ;)

  190. MattJ

    I've not been following any of these XEPs, and I suddenly feel how it must feel to non-XMPP folk trying to get stuff done

  191. daniel

    yeah i'll let you people figure that stuff out and then just implement what ever the best practices turn out to be

  192. Kev

    MattJ: That's actually why I think a meta-XMPP2 XEP like https://github.com/Kev/xeps/blob/58153226d6caf93fbb2b4d3fbd9819e814942e37/inbox/multi-client.xml is going to be important.

  193. Tobias

    daniel, sensible :)

  194. Kev

    Or the Compliance Suites remastered as just Current XMPP Version

  195. SamWhited

    That's an interesting idea

  196. Zash

    Hm?

  197. SamWhited

    I like it; though I'd be even more worried about us never releasing them and them ending up in a state where no one is really working on them.

  198. Zash

    Separation of "This is what's implemented today" and "This is what we want the future to be like" ?

  199. SamWhited

    I don't think it has to be imlemented today, it can also be "this is what the next version of XMPP looks like, now go implement it" as long as the specs exist.

  200. Zash

    Hm?

  201. Zash

    A document describing "Currently, implementations are doing this and that."

  202. Zash

    And, in a separate document, something of a vision statement.

  203. Kev

    I think what Zash says has considerable value.

  204. Kev

    Or something along those lines.

  205. MattJ

    +1

  206. Dave Cridland

    I think the two are needed - ie, "this is what is done now", and "this is where we'd like to be".

  207. Kev

    I wouldn't 'this is where we'd like it to be' as much as 'this is what we expect the next version of Done Now to be', but something along those lines.

  208. Zash

    In various non-profits I've been involved in, at the member meetings, there's usually one point of order for a report what the org has done since the last meeting, and a point about what the org is to do for the next period.

  209. Zash

    So, something corresponding to that is what I'm thinking.

  210. Zash

    Tho I can see how this could be three things

  211. Zash

    1) State of XMPP today 2) Expected of XMPP tomorrow (short term, in-progress things) 3) Long term vision (what we want XMPP to be in some magical future)

  212. Kev

    I don't see a reason 2/3 can't be a single XEP, but I'd be kinda keen on (1) being one of its own.

  213. Zash

    Kev: Sure. I suppose one could differentiate between 2 vs 3 into "things doable this term" and "things after this term" (roughtly council/board terms)

  214. Zash

    Having snapshots of how the state of things were in the past would be nice to have in the future.

  215. Maranda

    huhuhuhu http://www.mailenable.com/beta/Premium-ReleaseNotes.txt

  216. Maranda

    I don't even dare looking.

  217. Maranda

    But something in there "supports" OMEMO ™ (!)

  218. Zash

    Kev: `<example caption='Server acknowledges enabling Carbons'>` s/carbons/im-ng/ ?

  219. Kev

    Yeah. Spot the copy/paste.

  220. Dave Cridland

    Kev, Have you been using my trick of declaring the namespace in an entity to make bumping it easier? :-)

  221. jonasw

    does that even work with CDATA?

  222. Dave Cridland

    jonasw, No, nothing at all works inside CDATA, so i have to terminate the CDATA section, do the entity, and reopen.

  223. moparisthebest

    Maranda, it doesn't say it supports OMEMO, it says it "Advertises OMEMO Support" :P

  224. Dave Cridland

    jonasw, Saves me remembering what I chose for the namespaces, though.

  225. jonasw

    Dave Cridland, ah that makes sense

  226. Maranda

    moparisthebest, JSXC supports OMEMO *I think*

  227. Maranda

    moparisthebest, else it doesn't make sense

  228. moparisthebest

    it didn't last time I saw it but that sounds good

  229. Maranda

    moparisthebest, the funny thing is that they "added" all these features but still manage to not get how to output rfc compliant JSON.

  230. jonasw

    Syndace, regarding the magic values from the signal code, if we ever define our own ones/our own wire format, we won’t be compatible with the libsingal clients anymore, will we?

  231. Zash

    Doomed!

  232. Syndace

    jonasw, yeah, that's the reason why I copied these magic values in the first place - to be compatible to the current libsignal clients.

  233. Zash

    Are magic numbers copyrightable?

  234. daniel

    Are you asking oracle that question?

  235. jonasw

    :(

  236. jonasw

    can we agree on #nuketheentiresitefromorbit oracle?

  237. Syndace

    Zash: That's the actual question. I don't know, that's why I take the safe route and go with GPL for now.

  238. moparisthebest

    do you know oracle actually put a poem as the first bytes in their database protocol?

  239. moparisthebest

    specifically on the theory that poems are non-trivial copyrightable works, and that now no one can write an alternative implementation for oracle databases

  240. moparisthebest

    oracle is after all, 95% lawyers and 5% programmers right?

  241. Syndace

    Why are people like this :O

  242. moparisthebest

    s/people/lawyers/

  243. jonasw

    what the actual f*

  244. moparisthebest

    https://dacut.blogspot.co.uk/2008/03/oracle-poetry.html

  245. Neustradamus

    About MUJI: https://xmpp.org/extensions/xep-0272.html The 0.2 is not on the website, an idea? I found an old version in inbox: https://xmpp.org/extensions/inbox/muji.html (before the 0.1) -> https://github.com/valeriansaliou/giggle/blob/master/PROTOCOL.md

  246. jonasw

    Neustradamus, what are you asking for?

  247. jonasw

    0.1 is greater htan the 0.0.0.2 in the inbox

  248. Neustradamus

    Yes it is old in inbox

  249. Neustradamus

    But there is no 0.2

  250. jonasw

    was there ever a 0.2?

  251. Neustradamus

    There is not the standard? https://github.com/valeriansaliou/giggle/blob/master/PROTOCOL.md XMPP Extensions (Updated) - XEP-0272: Multiparty Jingle (Muji) v0.2

  252. jonasw

    dunno where giggle got that v0.2 from

  253. jonasw

    but if it’s not on the website, I doubt it exists

  254. jonasw

    0.1 is from before the git-svn import

  255. Neustradamus

    Ok it confirms my ticket: https://github.com/valeriansaliou/giggle/issues/90

  256. Holger

    Kev: IM-NG currently doesn't allow for sending (delivery) errors to all clients, right?

  257. Holger

    Don't we need that?

  258. Kev

    Did I miss that out? Full-JID errors go to all clients unless there's an im-ng element.

  259. Kev

    (because errors should flip the to/from and therefore will have a full-JID to)

  260. Holger

    Ah.

  261. Holger

    I don't see this being mentioned, but maybe I'm just overlooking it.

  262. Holger

    Kev: And I don't quite get the idea with sending to a single resource? The sender adds an <im-ng/> element, but the recipient should then ignore the message?

  263. Kev

    It's a protection (happy to believe I've worded it badly) against having things that look like IM messages, but don't get stored in the archive because of sender trickery.

  264. Kev

    So a client should only handle full-JID messages for things that are specifically needing to be full-JID messages.

  265. Holger

    Yeah I was going to ask about the meaning of "IM-related messages".

  266. Kev

    But if you received eg. <body>Yep, I'm saying this on the record</body> to a full JID you wouldn't render it in your chat.

  267. Holger

    So e.g. a MAM message is not an "IM-related message".

  268. Holger

    Right.

  269. Holger

    Then again you would render a MAM message :-)

  270. Kev

    I also forgot to put any reflection in there.

  271. Kev

    But there are words on a (virtual) page now, and that's one step closer.

  272. daniel

    So outgoing messages need to be tagged with im-ng? Could the server do that for me?

  273. daniel

    If I have enabled im-ng in that session

  274. Kev

    Yes, I suppose it could.

  275. Kev

    Only outgoing messages that are to a full-JID.

  276. daniel

    Example 5 gas that Tag as well though?

  277. Kev

    Because I'm an idiot :)

  278. Kev

    Gone now.

  279. Kev

    Holger: The error confusion is because I messed up. The paragraph should have been: <p>In order for interoperability with other entities (contacts, remote servers etc.) that don't support IM-NG, old-style full-JID messages also need to be handled. When a server receives a message with type other than than 'groupchat' or 'headline' that does not contain an &lt;im-ng xmlns='urn:xmpp:im-ng:0'&gt; element it is to be routed by the above rules as if they were sent to the bare JID</p>

  280. Holger

    Ah, makes sense.

  281. daniel

    Kev: by not process messages to the full jid you mean unless it's a "system message"

  282. daniel

    That was somewhat requested

  283. daniel

    In the security considerations

  284. Kev

    daniel: The text needs massaging. What I really mean is 'if you get a thing to a full JID that you expect to be to a bare JID, ignore it'.

  285. Kev

    So if you get a <body>something</body> to a full JID, you'd ignore it.

  286. moparisthebest

    couldn't (shouldn't) the server filter that?

  287. daniel

    The rules are probably too complex for a sever to grasp

  288. moparisthebest

    so another MIX? :P

  289. daniel

    I mean in the case of something obvious as body sure

  290. Kev

    The server just routes.

  291. Kev

    The client gets to decide how to handle what it receives.

  292. moparisthebest

    routes and also adds im-ng tag, seems like it could also block bad messages

  293. Holger

    Kev: But what you described regarding error messages would be the regular way of doing things, not just for interop with the old world, no? So if this was *only* mentioned in the above paragraph this intention would still not be obvious to me.

  294. Holger

    Kev: The first Business Rule sentence mentions all types except error, I think I'd add a sentence regarding errors following that.

  295. Kev

    Fair. I was pondering the same, ta.