Regarding the last votes of previous Council, and dangling Last Calls:
[voting-summary format = (-1 count : 0 count : +1 count)]
Final Votes Last Period:
VETO (-4:0:+1) 14/11/2018 Advance XEP-0357 (Push Notifications) to DRAFT
VETO (-3:0:+2) 14/11/2018 Advance XEP-0359 (Unique and Stable S
http://logs.xmpp.org/council/2018-12-12/#16:02:26
1) Roll Call
Present: Jonas, Link, Georg, Dave, Kev
2a) Proposed XMPP Extension: Simple Buttons -
https://xmpp.org/extensions/inbox/buttons.html
Jonas is not happy about the editorial quality of this one.
Georg asks if there are any functionally
A few thoughts (some of which have already been touched on by others)…
* clicking a button results in a textual message that provides no indication
that it came from a button press as opposed to being typed (I could type "yes"
for some other reason and you'd interpret it as a button press.) I un
> Maybe it would be sufficient to have a separate
> section on the xmpp.org website where one has the current compliance suite as
> home page and the older revisions on the sidebar. It could be linked from the
> main menu, making it extremely discoverable.
Yes, I actually came up with a similar ide
Having the Compliance Suites in an XEP feels somewhat out of place to me - an
XEP listing other XEPs (I know many XEPs refer to others, but it's not the
same.)
Would it be better to run it as a separate set of documents - XMPP Compliance
Suites (XCS)? This would have the benefit of making them m
http://logs.xmpp.org/council/2018-12-05/#16:00:08
1) Roll Call
Present: Jonas, Kev, Dave, Georg
Disparu: Link
3.1) AOB
Jonas suggests making use of the time while waiting for late-comers to discuss
an AOB point about the Compliance Suites, as he agreed to do the next
iteration. Jonas wonders wh
http://logs.xmpp.org/council/2018-11-28/#16:01:44
1) Presence
Available: Link, Dave, Jonas, Georg
XA: Kev (I probably can't make the meeting today.)
Dave is a little reticent to hold the first meeting of the new Council without
everyone present - given the need to select a chairperson.
2) Messa
http://logs.xmpp.org/council/2018-11-21/#16:00:06
1) Is there anybody out there?
Out there: Georg, Dave, Kev, Daniel
Way out there: Sam
2) Agenda
Dave assumes the only items for voting are those outstanding from last week,
and that nobody is mad enough to try adding something new; Georg consider
http://logs.xmpp.org/council/2018-11-14/#16:01:26
Kev rounds up the troops.
1) Roll call
Present: Georg, Kev, Sam
Apologies: Daniel
Missing, presumed alive: Dave
2) Agenda
Kev takes one look at the long list of potential items and proposes putting
everything off until next week, under the mista
Replying directly to the Last Call notifications and answering the 5 questions
would be most effective 😉
LAST CALL: XEP-0357 (Push Notifications) -
https://mail.jabber.org/pipermail/standards/2018-October/035415.html
LAST CALL: XEP-0359 (Unique and Stable Stanza IDs) -
https://mail.jabber.org/
ject: Re: [Standards] Council Pick-N-Mix Agenda 2018-11-14
On Dienstag, 13. November 2018 18:01:04 CET Tedd Sterr wrote:
> This will be the penultimate meeting before Council change-over, and likely
> the final productive meeting (one week remains for voting.)
I think it is the second-to-la
Which is precisely the point of prividing feedback to the Last Call, even if
it's in the form of "Yes, this is perfect as-is, please make it darft now!"
Silence could just as easily indicate no interest.
From: Standards on behalf of Ненахов Андрей
Sent: 13 No
This will be the penultimate meeting before Council change-over, and likely the
final productive meeting (one week remains for voting.)
This is a list of posssible of agenda items for the Chair can pick-and-choose
according to what they believe might stand a chance of being completed.
Reply with
http://logs.xmpp.org/council/2018-11-07/#16:03:11
Dave is here, but potentially not, and so asks Georg to chair; Georg graciously
accepts.
1) Roll Call
Present: Georg, Dave, Daniel, Sam
Apologies: Kev
2) Lack of Agenda Bashing
Georg made a poor attempt at sneaking https://github.com/xsf/xeps/is
http://logs.xmpp.org/council/2018-10-31/#16:00:00
1) Is There Anybody Out There?
Out There: Daniel, Dave, Georg, Kev, Sam
2) Items for a vote
Dave doesn't think there are any, but also didn't do much prep. for this
meeting.
Georg suggests that Somebody ought to sort out the SoD to determine whic
> [European and UK time revert from Daylight Saving Time (DST) on Sunday
> (28th), at 0100 UTC, effectively moving the next meeting to 1 hour earlier
> for those in other time zones. North America follows suit the Sunday after.]
Sorry, that should say "moving the next meeting to 1 hour _later_ f
http://logs.xmpp.org/council/2018-10-24/#15:00:46
Kev pre-emptively votes -0 for PR #706, for expediency.
Dave updates the SoD. Georg asks what happens to all of the expired votes -
Dave says all missing votes are assumed to be abstaining.
1) Who else is here apart from Kev?
Here and Kev: Kev
He
http://logs.xmpp.org/council/2018-10-17/#15:00:15
1) Is There Anybody Out There?
Present: Dave, Georg, Sam, Daniel
Apologies: Kev
2) Matters for Voting
Dave doesn't think there's anything new; PR #706 is still open, and several
other things have expired.
Georg thinks XEPs 0359 and 0357 have bee
> 2) PR #706 - Update BCP 14 language to comply with RFC 8174 -
> https://github.com/xsf/xeps/pull/706
I have to wonder whether "an implementation must" could mean anything different
from "an implementation MUST" -- how else could it be interpreted? Would 'must'
mean it's actually not mandatory
http://logs.xmpp.org/council/2018-10-10/#14:59:26
[Due to technical difficulties, the day's log is extremely patchy, such that
much of the meeting content is missing.]
1) Who's Here Anyway?
Present: Kev, Georg, Dave
Technical difficulties: Daniel
Whereabouts unknown: Sam
2) PR #706 - Update BCP
http://logs.xmpp.org/council/2018-10-03/#15:03:54
1) Roll Call
Present: Kev, Daniel, Sam
More not here than here: Georg
Even more not here than here: Dave
2) Agenda Bashing
Kev says "Cool."
3a) Proposed XMPP Extension: Bookmarks Conversion -
https://xmpp.org/extensions/inbox/bookmarks-conversio
http://logs.xmpp.org/council/2018-09-26/#15:02:01
1) Who?
Present: Georg, Daniel, Sam
Apologies: Kev
Astray: Dave
2) What?
Georg searches for an agenda, and muses on Dave's lack of a proper leave
message.
Daniel suggests the possibility of voting on the Bookmark Conversion proto-XEP,
except tha
> 1.111) AOB
> Georg notices PRs #591 and #598, which were vetoed, and asks if anyone
> remembers what the next steps were for them.
> Sam thinks they should be closed, and if the authors want to change things
> they can submit new PRs; Sam vaguely remembers that having more optional
> things didn'
http://logs.xmpp.org/council/2018-09-19/#15:01:24
Judge Georg presiding…
1) Rôle Call
Present: Georg, Sam, Daniel
Apologies: Kev
Deviant: Dave
1.1) Agenda Fumbling
Georg asks for agenda items; Sam hasn't seen any new proto-XEPs come in; Daniel
motions towards GitHub.
Jonas mentions Guus's PR (#
http://logs.xmpp.org/council/2018-09-12/#15:02:32
1) Roll Call
Present: Dave, Daniel, Sam
Apologies: Kev
Holidays: Georg
2) Items for a vote
Dave goes hunting, but doesn't see any in PRs, nor nay new ProtoXEPs; Sam
doesn't recall any.
3) Outstanding Votes
Dave thinks everyone has outstanding vo
I agree with your underlying point, but I think -1 gives the impression there's
something wrong with this as a solution - something should definitely be done
about the 'avatar situation,' but this is documenting an acceptable solution,
not adding additional pointless features.
0054 is vcard-te
http://logs.xmpp.org/council/2018-09-05/#15:01:43
1) Roll Call
Present: Dave, Kev, Sam, Daniel
Urlaubend: Georg
2a) MUC Avatars -- https://xmpp.org/extensions/inbox/muc-avatars.html
Dave would like to understand how it differs from the de-facto that it suggests
exists; the author says he tried t
http://logs.xmpp.org/council/2018-08-29/#15:05:41
1) Roll Call
Present: Daniel, Kev, Sam
Absent: Dave, Georg
2) Date of Next
2018-09-05 1500 UTC
3) AOB
Sam believes there was a proto-XEP, but is pretty sure it can wait until next
week - Jonas says it's not published anyway - so it can wait.
Lin
Summary of Latest Votes
AKA: The Number of Expired Votes is Too Damn High
2018-06-20
Advance XEP-0363: HTTP File Upload
https://xmpp.org/extensions/xep-0363.html
Daniel: +1
Dave: [expired]
Georg: +1
Kev: [expired]
Sam: +1
EXPIRED
2018-06-20
Deprecate XEP-0229: Stream Compression with LZW (and XE
http://logs.xmpp.org/council/2018-08-22/#15:02:02
1) Who do we have?
Present: Dave, Kev*, Daniel, Sam
Apologies: Kev
Incommunicado: Georg
1.5) Agenda
Dave is 95% sure that all of the GitHub PRs have been voted on and suspects
that some have expired; in view of that, he suggests not having a meet
I understand that it's summer, and people are busy, and assorted reasons, but…
https://i.imgur.com/MpDirHY.png
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_
http://logs.xmpp.org/council/2018-08-15/#15:00:06
In which there is a hidden agenda…
1) Is there anybody here?
Here: Dave, Kev, Sam
Half-here: Georg
Not Here: Daniel
2) Does anyone want to discuss anything since there is no agenda items?
No.
3) Let's just meet next week then?
Yes.
Kev will pro
http://logs.xmpp.org/council/2018-08-08/#15:00:48
In which there is much on-listing…
1) Rolls
Present: Kev, Georg, Sam, Daniel
Apologies: Dave
2) PR #693 - XEP-0060: Remove unused 'node' attribute on pubsub#event item -
https://github.com/xsf/xeps/pull/693
Kev: [on-list] (didn't get a chance to
Executing arbitrary code on the client? Kill it with fire!
I'd guess this is a case of trying to be overly-flexible in the hope of
covering all possible unspecified use-cases.
I wouldn't even expect that most clients can execute XSLT. And if the aim is to
generate a data-dependent form, is ther
http://logs.xmpp.org/council/2018-08-01/#14:59:59
1) Roll Call
Present: Sam, Dave, Kev, Georg
Pursuing business interests in the Middle Kingdom: Daniel
2) Agenda Bashing
No agenda changes; Georg liked it, but didn't put a ring on it.
3a) PR #681 - XEP-0050: Remove the status attribute from the r
> I'd rather call it 'extended chat state notifications' or something
> like that. Recording audio is only distantly related to file sharing.
"Media Stream Activity Notifications (MSAN)", then.
But it's good that we're putting so much effort into arguing over the important
details, rather than t
http://logs.xmpp.org/council/2018-07-18/#14:59:12
As Dave will be train-hopping, he asks Kev to chair this meeting - who
graciously accepts.
1) Roll Call
Present: Kev, Daniel, Georg, Sam, Dave
2) Agenda Bashing
[Nobody can find an agenda to bash.]
3) Date of Next
Neither Kev, Daniel, nor Sam a
http://logs.xmpp.org/council/2018-07-11/#15:00:11
1) Role Call
Present: Kev, Dave, Sam, Georg, Daniel -- Full House!
2) Agenda Fiddling
Dave thinks Tedd's agenda seems OK and decides to go along with it.
3) PR #664 - XEP-0045: Add implementation note about {jabber:x:conference}x
payload - https
The XMPP Council will be holding its regular meeting today (Wednesday) at 1500
UTC.
The agenda is collated from (in order of reliability):
* Github pull requests marked "Needs Council"
* Random mails from Standards List
* Random suggestions directly to Chair
* Trello at https://trello.com/b/ww
One can certainly send a disco#info to server on which you don't have an
account, and the response is as expected, but that still requires an account on
_a_ server - so the reply can be directed to you.
For pre-registration, I think support would have to be listed as a Stream
Feature.
That sai
http://logs.xmpp.org/council/2018-07-04/#14:47:03
1) Roll Call
Present: Kev, Georg
Tried in absentia: Dave, Sam, Daniel
2) Agenda Bashing
[The agenda is bashed beyond all recognition.]
3) Outstanding Votes
[Several votes are left dismayed at their waning chances of gaining legitimacy.]
4) AOB
[
http://logs.xmpp.org/council/2018-06-27/#15:01:21
1) Baps
Present: Georg, Kev, Daniel, Sam
Apologies: Dave
2) Agenda Bashing
Georg mutters something, possibly in German, that sounds a lot like
"compression" - Kev requests elaboration.
Georg thinks the reasons for considering Stream Compression i
I think being informed of the server's retention policy is definitely useful;
the server already returns a 'max-file-size' as part of its disco reply, so it
should be simple to include a 'file-expires-time' value indication the number
of seconds before which the file is automatically deleted.
> FWIW, since I was one of those (if there even were multiple) who made a joke
> about that, I want to make sure it’s received as a joke, too.
Yes, all in jest, don't worry.
You'll be hearing from my lawyer!
___
Standards mailing list
Info: https://m
> On Stream Compression: as TLS is pretty much a requirement now and it already
> does compression (unless explicitly disabled), wouldn't that make Stream
> Compression surplus to requirements at this point?
Nevermind; support for compression is dropped from TLS as of version 1.3, for
security
Contrary to vicious rumours floating around, I have no interest in supplanting
Dave's position as Chair.
With only a few hours remaining and no agenda forthcoming, I thought a meeting
with some agenda would be better than with none - and the agenda is largely
straightforward.
Why was "Deprecate
http://logs.xmpp.org/council/2018-06-20/#15:00:27
1) Roll Call and Sandwich Orders
Present: Kev, Sam, Daniel
Stuck in endless meetings: Dave
Deep under-cover behind enemy lines: Georg
2) Isn't it nice that Tedd Sterr does the agenda?
[It's a dirty job, but somebody should do it.]
3) A
The XMPP Council will be holding its regular meeting today at 1500 UTC.
The agenda is collated from (in order of reliability):
* Github pull requests marked "Needs Council".
* Trello at https://trello.com/b/ww7zWMlI/xmpp-council-agenda
* Random mails from Standards List
* Random suggestions dir
> 1½) Isn't it Nice when Tedd Sterr does the minutes?
https://gfycat.com/SpottedRecklessIndusriverdolphin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
> I don't want to put words in anybody's mouth, but to me it looks like
> Kev said it would be better to bump this than to have a second
> specification, not that changing this spec needs a bump.
"That was my original expectation too, but Kev suggested the bump would be
preferable. [...to a secon
> This wouldn’t be an issue if clients use sufficiently unique IDs.
I'm not sure that magically fixes the issue.
New RMC clients can and should use unique IDs - and we can mandate that - but
the issue here is with older LMC non-RMC-aware clients.So, if those clients
expect LMC to only ever be ap
http://logs.xmpp.org/council/2018-06-13/#15:03:33
Dave apologises for not preparing an agenda; apparently, having a day job is
distracting.
1) Roll Call
Present: Kev, Daniel, Sam, Dave
Away on a top-secret mission: Georg
2) Agenda Bash
Dave is unaware of anything that needs a vote, and asks whe
> It sounded to me like this would be a new distinct namespace
> older-than-previous-message corrections, a namespace bump may be more
> contentious in a draft XEP.
That was my original expectation too, but Kev suggested the bump would be
preferable.
> As I see it, the *worst* thing that will
> What is the worst thing that happens if we just change this Draft?
As long as it doesn't confuse existing implementations, hopefully nothing; but
I suppose that's what the namespace bump is for.
___
Standards mailing list
Info: https://mail.jabber.o
> Is that essentially https://xmpp.org/extensions/inbox/message-retraction.html
> ?
The intent is roughly the same, though this looks to be aimed more at use in
MUC, and has additional complexities as a result.
I think considering deletion as a correction makes some sense, though I can see
h
> I think an ns bump in 308 is better than a duplicate spec, really (unless
> there’s something I’m missing).
I'm not strongly for a new spec., though I thought it might be more appropriate
in this case given the aversion to changing Drafts and that it's already well
implemented; also avoiding
I have considered this issue previously and concluded that, while there appears
to be no technical reason to disallow correcting older messages, (some) current
implementations only support correction of the last message (in line with this
limitation.)
Maybe Kev can shed some light on why this l
I should note that this list is for XMPP Standards discussion, and development
questions are more appropriately directed to the JDev list -
https://mail.jabber.org/mailman/listinfo/jdev
___
Standards mailing list
Info: https://mail.jabber.org/mailman/l
It sounds like you're trying to take the incoming XML stream as-is and separate
it into stanzas without properly parsing the XML. You will need to parse the
XML anyway to make use of it, so you may as well do it as it comes in.
Buffer the incoming raw data, and then parse XML components, and com
http://logs.xmpp.org/council/2018-06-06/#15:01:24
1) Roll Call - https://en.wikipedia.org/wiki/Roll_Call_(Hank_Mobley_album)
Present: Dave, Kev, Daniel, Sam
Indisposed: Georg
2) Isn't it nice that Tedd Sterr does the minutes?
Dave pokes the dead horse again to make sure it really is dead
> 2) Isn't it nice that Tedd Sterr does the minutes?
Come on, you need a new joke now - this one started wearing thin weeks ago 🙄
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-
> However, I could move it out into a new MIX-NICK. What do people think?
You could probably move channels into a separate XEP too, and messages, and
nodes, and maybe a few other things.
I think if you really try, you could probably get MIX up to at least 24
separate XEPs - that would be pr
http://logs.xmpp.org/council/2018-05-30/#15:00:13
1) Roll Call - https://en.wikipedia.org/wiki/Roll_Call
Present: Kev, Daniel, Georg, Sam
Better things to do: Dave
2) Isn't it nice that Tedd Sterr does the minutes?
There are no dissenting voices.
3) Proposed XMPP Extension: Terms of Ser
http://logs.xmpp.org/council/2018-05-23/#15:01:25
1) Roll Call - https://en.wikipedia.org/wiki/Roll_Call
Present: Dave, Kev, Georg, Daniel
Absent: Sam
538aba95-6e07-4d40-709b-f0ba0562c49f) Lack-of-Agenda Bashing
Dave admits to having deliberately neglected the agenda, and suggests not
having a m
Fist impression: eight is a lot! (There's a lot of functionality to cover, I
know.)
I presume the intention of splitting up MIX is to make it easier to both
understand and implement, however, purely separating a large document into
multiple smaller ones doesn't immediately achieve this (it just
http://logs.xmpp.org/council/2018-05-16/#15:04:51
1) Roll Call - https://en.wikipedia.org/wiki/Roll_Call_(IQ_album)
Present: Dave, Daniel, Sam, Georg, Kev
2) Isn't it nice that Tedd Sterr does the minutes?
Dave's reprises his role as the inveterate fangirl, complete with sq
http://logs.xmpp.org/council/2018-05-09/#15:00:03
1) Roll Call - https://en.wikipedia.org/wiki/The_Roll_Call
Present: Dave, Daniel, Sam, Kev
Apologies: Georg
2) I wonder if Tedd Sterr is doing the minutes
(Tedd has already confirmed willingness to do the minutes until further notice.)
Dave would
> 2) I wonder if Tedd Sterr is doing the minutes?
Tedd Sterr is happy to continue doing the minutes until further notice.
A rogue usurper decided to do them last week; future celebrity contributions
are also welcome. 😉
___
Standards mailing l
http://logs.xmpp.org/council/2018-04-25/#15:01:05
1) Roll Call
Apologies: Kev, Georg, Dave
Commiserations: Sam, Daniel
2) Agenda Bashing
Nobody is impressed with this empty agenda, but has nothing further to add.
3) Outstanding Votes -
https://docs.google.com/spreadsheets/d/1AZ-Sna6OiRG--b-mJMK
> Another note: the council may generally want to advance a XEP but vote
> not to issue Last Call because of outstanding issues. We don't have a
> special status for that. I can think of a number of XEPs in that
> category.
outstanding_issues 😀
(Though this doesn't seem entirely different from
'Proposed' represents an intermediate state of "Experimental + awaiting vote to
advance to Draft." The outcome of such vote, may either be: success (advance to
draft), failure (rejected), or changes needed (..limbo).
I think that rejected represents an irredeemable failure, which is why it's so
Okay, thanks for the feedback - summaries shall continue! 😁
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Apologies for the delay - trying to untangle and distil the XEP-0050 discussion
was 'fun.'
On a related note: though I'm happy to continue summarising, do people find it
useful, or is it more detail than necessary?
___
Standards mailing list
Info: htt
http://logs.xmpp.org/council/2018-04-18/#15:01:38
1) Roll Call
Present: Sam, Dave, Kev, Georg
Absconding: Daniel
2) Last Minute Agenda Bashing
Dave asks whether there is anything to add to the agenda - Sam is not aware of
anything.
3) XEP-0050 'execute' Issue
Dave asks Kev if he wants kick this
As Dave is overtly busy, I'll make something up and you can all just go along
with it...
The XMPP Council will be holding its regular meeting tomorrow (Wednesday) at
1500 UTC.
The agenda is collated from (in order of reliability):
* Github pull requests marked "Needs Council".
* Trello at http
So how would a client choose whether/when to send a mediated invitation or
direct invitation?
If mediated invitations can't necessarily be trusted, or won't necessarily even
be received, are they useless?
Always send a direct invitation? Send mediated, wait 10 minutes, then direct if
no reply?
XEP-0249 (Direct MUC Invitations) appears to be aimed at working around privacy
lists (XEP-0016) blocking, but since privacy lists are now deprecated, does it
have any other uses cases?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/l
> Is this multi-user chat customizable to where users respond to texts in order
> of joining group and invites.
XEP-0045 already supports inivites (see 7.8.2); the recipient can accept or
decline the invitation, and provide a message to say why.
It's entirely possible for your client to do so
> But we might never know if someone is building an application or service
> on top of a library...
Isn't this the point of the CFE - to find out?
There is always the *possibility* that somebody somewhere could possibly maybe
have implemented a given feature, but if nobody knows about it, do we j
ty for one meeting.
3) Minute Taker
Either Tedd Sterr will do it or else Dave will.
Goerg mentions that the abolition of Pidgin is a Board agendum now.
Dave tries to figure out which CFEs have completed; Jonas says 0131, 0141, and
0229.
4) Advance to Final XEP-0131: Stanza Headers and Interne
http://logs.xmpp.org/council/2018-04-04/#15:01:00
Kev is ill today, but will heroically try to make it through the meeting.
1) Role Call
Present: Kev, Dave, Daniel, Georg, Sam.
2) I do hope Tedd Sterr is doing the minutes again
Three cheers for Tedd.
3) XEP-0050 (Outstanding issue about
> We would also welcome a volunteer to take minutes (please - PLEASE - reply to
> this message if you can take this on).
Since I'll probably end up doing them anyway, let's make it official and say
I'll do them until further notice; though I likely won't be present for the
meeting itself, so th
I think I've managed to successfully implement XEP-0239 - at least it looks
correct to me - however, I'm unable to find any servers that support it.
Does anybody know of a server that supports this so I can test it properly?
___
Standards mailing list
http://logs.xmpp.org/council/2018-03-28/#15:14:31
1) Role Call
Present: Kev, Dave, Daniel, Sam, Georg
2) Minutes
'Dave' will do them this week..
3) Agenda Bashing
Dave thinks there is just the Advancement of XEP-0092 and XEP-0122, plus
outstanding votes from last week; there are no objections.
http://logs.xmpp.org/council/2018-03-21/#16:00:28
Dave warns he's on a train and may not manage to achieve all 4 of the necessary
Gs.
1) Roll Call
Dave orders bacon and cheese, Georg wants the same; Sam wants cheese on all the
things.
Present: Dave, Georg, Sam, Kev.
AWOL: Daniel
.) For fork's
I didn't expect this to turn into a drawn-out argument; I merely suggested a
simple solution to something that could otherwise be seen as a problem. Nor am
I continuing it for my own amusement, but I genuinely don't understand why it's
such a contentious issue for some.
So far the main argument
> This is true, however mostly these are quite coarse-grained. Extensions with
> lots of optional
> parts inside - I'm thinking about XEP-0060 for example - tend to end up with
> various interop issues.
I don't disagree with that, and I'm not suggesting 0394 turns into a mass of
optional parts
> If you ever intend to make XMPP adopted by masses, zillion of optional
> features is actually a bad solution.
XMPP is nothing but optional features!
Beyond XMPP-CORE and XMPP-IM, everything else is optional.
See https://xmpp.org/extensions/ for just how many optional features there are.
___
> XMPP can offer so many possibilities to it's users. Everyone can have
> a very special capability that only he and his chat partner will use.
> The downside is that total userbase would be 700 users.
> With so many unsolved problems concentrating on features that worsen
> UX and make client devel
I really don't see the problem - clients would surely implement such things?
They could, but they're not required to.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_
> Sender can't know what color scheme recipient has. It can be light or
> dark mode, where colors are inverted. There is no way to make text
> look consistently good if it's using various colors, and attempt to
> display user-colored text would lead to chat window looking like
> Geocities-era websi
> It could be, but given that this was a feature before and no client ever
> implemented this
> I don't see why it's something we should suddenly rely on now.
It doesn't have to be relied upon - I suggested a simple solution to the
problem of lacking contrast between text and background colours.
From: Standards on behalf of Sam Whited
Sent: 15 March 2018 14:38
Subject: Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071
>> 4. Using different fonts, font sizes and colors, for the same as in 3
>> or as parts of congratulation cards: ~3%.
> This is an anti-pattern. It
I like the idea and design of 0394, and look forward to seeing these
extensions; the unholy hybrid attempting to shoehorn in 0393, not so much.
Attempting to extend the inline text styling to support all of the additional
formatting features is going to result in plain text messages that resembl
I have to agree with Kozlov - I struggle to tell the two apart on title alone.
I think the confusion comes more from both titles being variants of 'Message
Styling/Markup/Decoration.'
"Text Styling" seems a more fitting title for 0393.
From: Standards on beh
As mentioned, this has been suggested before, but the flexibility of being able
to mix-and-match XEPs means there's no simple way to do it.
At the simplest end, we try to decide on a strict subset of XEPs to be defined
as "XMPP-1.0"; this will ultimately fail as nobody can agree what should and
For reference, XEPs that list the given XEP as a dependency (to what extent
they actually make use of it is another matter):
XEP-0020 (Feature Negotiation; Draft; 2006-11-21)
- XEP-0041 (Reliable Entity Link; Retra)
- XEP-0052 (File Transfer; Retra)
- XEP-0116 (Encrypted Session Negotiation;
hanks for your feedback
Le dimanche 25 février 2018, 21:19:16 CET Tedd Sterr a écrit :
> The requestor should ask for the full path to the file, not the bare
> filename, so as long as you don't have two files with the same name in
> the same directory, there shouldn't be a conf
The following XEPs have been in Draft status for over 10 years; surely that
implies they are finished.
XEP-0020 (Feature Negotiation; Draft; 2006-11-21)
XEP-0048 (Bookmarks; Draft; 2007-11-07)
XEP-0059 (Result Set Management; Draft; 2006-09-20)
XEP-0066 (Out of Band Data; Draft; 2006-08-16)
XEP-
> For me the text and examples are not clear.
>
> „sha1-hash-of-image“ in the example doesn’t say anything about the encoding.
True. It appears to defer that to RFC-3174, but that document only specifies
how to calculate the hash value, not how to represent it (as a hex string.) It
seems to be m
301 - 400 of 408 matches
Mail list logo
