XMPP Council - 2013-11-20

kev: there needs to be a decision about the format first -- linuxwolf made me think (@ http://mail.jabber.org/pipermail/jingle/2013-November/002037.html ) that the hex-with-colons has some advantages over the raw-base64

and those advantages are?

all i can think of is simpler compatibility with sdp, but that's just a single application of this xep

not just sdp. that format is used by sdp because browsers and openssl use it

this might be a display issue, so it's a small decision

Is there a recommendation anywhere that iqs should return quickly?

Yes, but it's rather open to interpretation

It doesn't use the word "quickly"

Do you know where?

Somewhere, I'm looking to ensure I didn't imagine this sentence

I remember arguing with someone about it, so it exists somewhere I'm fairly sure

I'm having issues with how much of rayo is presence.

Or the two in the inbox, anyway.

Rayo itself using presence from epemeral JIDs to show them coming into play seems sensible enough.

(I don't see anything in RFC 6120 about quick responses to IQ requests)

kev: i have too...

mostly because I think that presence shouldn't be used for actual data

I'm unable to find the text that I'm thinking of :/

but that is for the core rayo spec

Maybe I'm confusing iq with something else

I'm pondering if saying "send this fax" shouldn't respond once the fax is sent, rather than immediately returning, and then later sending a presence with the result, which seems really wrong.

jingle has some precedence for iq-should-return-quickly -- we don't wait for the user to accept before sending the result

brb

It feels like doing what I was suggesting isn't quite right. I was wondering if we have anything written anywhere to support the feeling.

Regardless, I think the faux-result doesn't belong in presence :)

After skimming all the RFCs, I can only conclude I was mistake with my "Yes" to your original question

*mistaken

Ta.

How will we know when you're nodding if we have no video?

kev: i'm thinking that rayo itself uses presence in alot of cases where i don't know if it really fits

That may be fair.

looking at 0327 i'm also wondering about the rationale of putting urn:xmpp:rayo:client:1 into the node with a caps element

in fact, the whole usage of node there...

yeah, that feels too much like an implementation hack

just FYI: i might be leaving earlier later, will send any remaining votes before weekend

Tobias, You might be leaving "earlier later"?

earlier than the council end, later on this day :)

'tis time.

1) Roll call.

here

here

here

MattJ, ping

Here

Laggy, but here

Excellent.

2 - http://xmpp.org/extensions/inbox/rayo-cpa.html

Accept as Experimental?

I have a number of reservations about this, not least of which that it seems to be reimplementing pubsub.

kev: i have similar objections, but not against this spec but against rayo

But...I'm not sure that justifies rejecting it.

don't we already have a DTMF xepß

I have reserverations about most of rayo, but i'm +1 for experimental for this since rayo is too

for cpa itself, the main issue i have is it getting its namespaces consistent

i'm +1 -- there are some nits i posted to standards@, but I'm sure ben langfied will fix them

Tobias: 181?

right, XEP-0181

yes

I don't think this is competing with 181.

Hmm, I'd forgotten about that one

tobias: 0181 is inside a jingle session. rayo is about call control

fippo, ahh...ok

so you might want notifications without being part of the session

right

I did spend a while re-reading 327 to remind myself this afternoon. There's lots there that doesn't sit quite right.

FWIW, i've heard a lengthy rant about rayo vs csta-xml from our csta-guy

I think Ben would be quite open to feedback

I think this is !-1 from Fippo, Lance, Kev.

Matt/Tobias?

+1 to accpting

i'm okay with accepting as experimental

Marvellous.

3 - http://xmpp.org/extensions/inbox/rayo-fax.html Accept as experimental?

haven't read that yet in detail

same reasoning as above, +1 experimental

found some broken links, ben promised to fix them so i'm +1 as well

my main question for the fax one is why splitting it into two namespaces?

I'm really not comfortable with using <presence/> in place of an <iq =result/>, but I think this falls under the whole 'too much presence in rayo' thing.

So I'm again OK with experimental.

Tobias: Is that a "will vote on list"?

MattJ?

Kev, yes

+1 to accepting

4) Adding tables to 71. Not really a Council action, but I'd like go gauge opinion here.

k...will read the rest of the log later..sry..g2g

Tobias: Bibi.

I'm ok wth adding tables to 71

I'm vaguely opposed to adding new elements to 71, in something that's Draft.

and... what next? :)

is 0071 extensible in a way that support for tables can be disco'd?

fippo: no

Well, sure it is, if we add the text on disco :)

yeah

But I feel like this doesn't fit into the spirit of non-backwards compatible changes for Draft, and shoving it in a new XEP with discovery would be appropriate.

but XEP-0071 wasn't designed that that in mind -- we could add it, though

Adding extensibility with no impact to the deployed base seems like something that could be added in Draft.

I apologize for being weeks behind on email, but what exactly is the use case? is this really an IM thing?

stpeter, I asked that on the list - the answer is yes

Dave Cridland: Yes, if we added discovery we could add it. But at that point, why bother?

stpeter: Yes, IM between non-humans.

Bot to user communications is the use case.

Peter Waher wants to be able to send tables of information from a bot or automated service

XHTML-IM was designed for IM use cases, not generalized communication

I'm not opposed to the use case

by "IM" I meant human to human communication, sorry

I'd just rather it went into another XEP than we bolted stuff onto 71 at this stage, but if I'm the only one I won't bother objecting to it.

You're not the only one

So could I get a feeling on whether people are OK with adding discovery+tables to 71?

I think if we start adding to 71 now, it'll be a slippery slope :)

Just a non-vote +-1 would be good.

a new XEP with discovery would make sense I think

aside from needing to improve the security considerations (thanks to Waqas), I would like to push XEP-0071 to Final in 2014

-1 -- a new xep with discovery seems like the better way

yeah, +1 for a new xep. i'm sure there are other issues that need fixing once we dive into it

OK, good enough, thanks.

I'll post thoughts to the list, then.

5) http://xmpp.org/extensions/inbox/eventlogging.html Experimental?

Lance: "other issues" as in things we need to fix in XHTML-IM?

We've stilll got a couple of items, and we're running out of time, so I'd like to press on.

(agreed Kev)

+1 experimental for event logging, going by peter's latest version on the list, not the inbox version

So, I'm not intrinsicly opossed to this one. There's a couple of warts that could do with tidying up, to my eye, but that's fine for Experimental.

i'll vote on list. this reminds me of things i've seen in the BEHAVE wg so i want to double-check there

Ah, I've only reviewed the inbox version.

So let's push this out for next meeting once it's in teh inbox.

Agreed

6) 134 (Design guidelines)

Fippo raised the issue of these being a little dated a while back.

oh yeah...

let me chech when that was...

stpeter: I'm going to guess you don't have time/energy to update this at the moment?

heh, "Last Updated: 2004-12-09"

"SI File Transfer [28] is a good example of respecting the strengths and weaknesses of XMPP" - :-)

That dates it a little.

oooooh :)

it probably does need a bit of updating, yes :-)

http://mail.jabber.org/pipermail/standards/2012-September/026812.html

I'd like either stpeter or someone else with Peter's blessing to volunteer to update this, I think.

Or, if that's not on the table, consider whether it should stay at Active.

stpeter: Thoughts?

this sounds like something for brussels or another f2f meeting

It actually looks mostly reasonable to me. Dated, and could use a little love, but essentially still solid.

after today I'll have more time to work on things, so I can add this to my .plan :P

There's certainly a bulk of sensible stuff in there.

dave: it lacks caps and pep

Sorry I was not available when you discussed IM in 0071. I can response in AOB later

stpeter: OK, thanks.

6) Date of next.

SBTSBC?

+1

wfm

wfm

I'll be offline next week, but have fun :-)

7) AOB?

two things

You have 30 seconds :)

there are the bosh changes that need to be reviewed

First the tables in 0071

XEP-0156 updates and BOSH patches

I'm reviewing BOSH

Peter Waher: I'll reply on list for that.

maybe the Council can consider those next week

(y)

stpeter: Are the BOSH versions published?

Kev: yes

Ah, I missed, sorry.

So yes, can vote next week.

the original reason for tables in XHTML-IM was to be able to create chat bots for IoT, where tabular output is necessary

http://xmpp.org/extensions/tmp/xep-0124-1.11.html and http://xmpp.org/extensions/tmp/xep-0206-1.4.html

Peter Waher: I think we can do this on-list.

(y)

Or here, after the meeting, which I want to close now :)

second item:

Dynamic Forms

I've made all updates you requested

even though it took a while

OK, is that in the Inbox again?

yes

Then I just suck. I'll add it to the agenda for next week, sorry.

(y)

Is that everyone/everything?

Seems so

for my part, yes

Marvellous.

thanks

Thanks all!

Thanks Kev :)

If you could update the eventlog XEP in the inbox

with the latest version with all corrections

stpeter: i dont know if there are any other issues in 71, but if we're going to make a 71bis, might as well inspect to see if there are any

Lance: there are security issues of the kind that Waqas raised in Portland

we need to add some strong wording to the security considerations

Peter Waher: So, the summary is just that I (and others) would rather see tables in a short extra spec with discovery than put into 71 at this late stage in its life. No opposition to the idea, I think.

Peter Waher: and yes we need to get you up and running with git access, or figure out a better way to get things updated under source control

If the problem is just entry into Git, I don't mind getting mailed a format-patch and pushing it.

stpeter: actually, could you check whether i have git access? sending you patches is silly :-)

Bear's suggestion was that he'd set up a two-way sync with github once Board decide they're comfortable with that submission method.

I'm testing that this weekend

ok, excellent

So, if you think a separate XEP is warranted for tabular data, I can write a proposal. Ok with everybody?

Or do we need to discuss this on-list, before a decision is taken?

I think a bit of discussion on the list would be good

Peter Waher, For purely tabular data, there is the forms stuff.

But that wouldn't get displayed in the chat window

I'll search for an example...

Example 1: Tabular data using normal text and tab characters:

http://twitpic.com/djmor4

(reading a device)

As tabular data (using Psi client)

http://twitpic.com/djrq2a

(and XHTML-IM containing tables)

Peter Waher: ah, that's nice :-)

Peter Waher, did Psi already allow that? or you added it?

Psi allows it

but only the most basic tables

for instance, I could not use text-align style

to align text within cells left/center/right for instance

(which would be nice)

heh, XEP-0071 says: Modularization of XHTML defines many additional modules, such as Table Modules, Form Modules, Object Modules, and Frame Modules. None of these modules is part of the XHTML-IM Integration Set. If support for such modules is desired, it MUST be defined in a separate and distinct integration set.

Correct, but the table XHTML module is "very" complex

yes

thus my concern

so, a limited subset would suffice

although many of the XHTML modules are complex

and we've subsetted most of them anyway

yes, but also, there are many restrictions in XHTML-IM

when it comes to attributes and especially styles

which is OK under the circumstances

exactly

During the discussion on list I proposed a mimimalistic subset

Peter Waher: great

Peter Waher: I'm sorry that I haven't posted in that thread, but I shall soon

(y)

http://xmpp.org/extensions/tmp/xep-0156-1.1.html <-- bosh updates include those, right?

(heh, since there is a link to the log in the minutes i don't even need to send an email)

heh

It's on my list.

Up to 8 items already.

oh, i can add another two :-)

question - i'm chatting with one of the moz wg-presence folks and he is asking about a reference doc on presence propagation

which XEP is that?

I don't understand the question.

that should be core 6120/1, right?

presence propagation?

If it's core presence handling, that's 6121

yes, presence handling thanks

Kev: what items do you have so far?

Bosh, Bosh, 156, dynamic forms, event handling, plus the boilerplate.

can presence be subscriptions be done by "group" ?

Presence subs are always 1:1

Most servers support shared roster groups of some sort, but that's an implementation detail.

thanks

yeah it would be good to standardize roster groups

in what way?

i think that MUC solves much more use cases than roster groups typically

hmm

yeah, now that I think about it I can't say that I care too much about shared roster groups :-)

Users care about shared roster groups - a lot

they do

We also have a Prosody plugin to inject MUC bookmarks based on group

which a number of people use

we've never succeeded in defining a common solution here, though

mattj: do they care about presence or chatting with a group of people?

Both

I know of people with 4K users in a single group :)

ouch

i recently had a case where a server crashes because 2000 people had subscribed to 1999 other peoples presence...

Yeah, it found some bottlenecks in our code :)

We managed to make Pidgin the bottleneck, which was where we drew the line

MUC has interesting scalability implications here ... i.e. you always send updates only to people that are in the muc

People do use offline messages

which isn't terribly helpful if all people are in the same timezone and working 9-to-5

The folk with large groups tend to use it as a way for employees to locate other employees

ah, non-anonymous muc then and smart clients

from yesterday's version of the wiki: https://wiki.mozilla.org/index.php?title=CloudServices/Presence&oldid=766337#Why_not_use_XMPP.3F

and wrong room tab, of course