[Standards] Re: Controlling XEP-0060 publish-options behaviour

st pubsub implementation thing, and a more general `read- only` option to prevent accidental config change could be interesting. The current behaviour with 2 rounds config change is already overriding stuff anyway, so this question is probably out of topic for the change you're willing to make. Be

[Standards] Re: Controlling XEP-0060 publish-options behaviour

, as long as nobody is deleting my blog posts by setting `max_item=1` instead of `max` this way. Best, Goffi Le mercredi 28 juin 2023, 13:26:02 CEST Matthew Wild a écrit : > Hi folks, > > Pubsub's is an important part of the protocol, e.g. > to ensure that private data stays priva

Re: [Standards] [XEP-0447] [XEP-0385] multiple files sharing + Highlander's "There Can Be Only One"

for attaching multiple files to (and pubsub). A new version of XEP-0447 is to be expected at some point with those changes. Regards, Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr

Re: [Standards] [XEP-0447] [XEP-0385] multiple files sharing + Highlander's "There Can Be Only One"

estriction. Le mardi 21 mars 2023, 11:44:13 CET Goffi a écrit : > Hi, > > Libervia is currently implementing XEP-0447 instead of SIMS as it is supposed > to be a reiteration of XEP-0385. However, it can't currently handle multiple > files in the same message because of §3.3 "

[Standards] [XEP-0447] [XEP-0385] multiple files sharing + Highlander's "There Can Be Only One"

e to move on XEP-0447, transfer author from XEP-0385 there, and deprecate XEP-0385. Thanks, Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Proposed XMPP Extension: Pubsub Signing: OpenPGP Profile

> create an implementation :) For the record, I have already made an implementation in Libervia (along with OpenPGP for XMPP Pubsub, and Pubsub Target Encryption). Normally the current specification are complete enough. Goffi ___ Standards mailing li

Re: [Standards] Proposed XMPP Extension: Pubsub Signing

Hi Paul, sorry I forgot to answer, I've got a lot on my minds these days… Le mercredi 9 novembre 2022, 14:01:27 CET Paul Schaub a écrit : > Hey! > > Thank you Goffi for creating this proposal. Cross-reading it, some > points come to mind: > > In the glossary under "sig

Re: [Standards] Proposed XMPP Extension: PubSub Social Feed

Thanks for your message. I got it and it indeed a useful feature-but it needs to specified in XEP-0060. Kind Regards Goffi Le 5 novembre 2022 14:33:37 GMT+01:00, Maxime Buquet a écrit : >On 2022/11/02, Goffi wrote: >> 'pubsub#type' would be "http://www.w3.org/2005/Atom; in an

Re: [Standards] Proposed XMPP Extension: PubSub Social Feed

> 'urn:xmpp:microblog:0' (there > https://xmpp.org/extensions/inbox/pubsub-social-feed.html#profile_microblog) > and not 'http://www.w3.org/2005/Atom' then I know that the node is > actually a bit more than "a Pubsub node with Atom items in it" and as a > client I can adapt my UI/UX to

Re: [Standards] Proposed XMPP Extension: PubSub Social Feed

t; in our case, so you should use (create?) an other metadata field to handle "profiles". Also, your proposal is using verbatim stuff from XEP-0277, I believe that original XEP-0277 authors should be quoted somewhere inside your specification. King Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Proposed XMPP Extension: PubSub Social Feed

ere. - what is this "Gallery profile" thing ? It looks like a terrible way to do photo galleries, ignoring all the work done by stuff like XEP-0447. Please, I see no good reason to have this. - style remark: quotes (notably in section 4.1) are not following XEP-0143 gui

Re: [Standards] Signing PubSub items (Proposed XMPP Extension: OpenPGP for XMPP Pubsub)

) Hi Debacle, I'm currently working on an other protoXEP that I should submit later today or tomorrow to handle the signing case, and it will support signing both plain text and e2ee items. There is a passage in security notice highlighting this. Cheers Goffi __

Re: [Standards] The Editor intends to resign

what you have done so far and your responsiveness, it has been very much appreciated. Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Proposed XMPP Extension: Events

Le vendredi 30 septembre 2022, 13:35:17 CEST Maxime Buquet a écrit : > Thanks Jonas! > > Thanks Goffi! > I have skimmed over the spec, and here are a few comments that shouldn't > pose any issue for the move to experimental. Hi Pep, > > > § 5. Events Nodes > >

Re: [Standards] Proposed XMPP Extension: Events

explicitly iCal metadata to the propose data form field type. Thus nothing is lost here Thanks for the feedbacks, and I hope that my points make sense to everybody. King regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Proposed XMPP Extension: Events

I was criticised. Thus I'm not sure if it's good to do it before council vote, but if you ask me, I have nothing against it and can do it sure. Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubs

Re: [Standards] Clarify meaning of pubsub#item_expire: creation or modification?

st anymore). Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Renaming XEP "Draft" stage to "Stable"

te", and indeed when you're not aware of the workflow, it seems like nearly nothing is usable (that's still true with many XEPs used widely which are in Experimental or Deferred state, but that's an other story). Thanks for taking care of

Re: [Standards] [XEP-0060] removing exception for last item when doing a node purge

if the item is remaining, and client has to do an extra and probably useless request each time. Regarding the lack of feedback I suppose that all implementation in the wild are removing all items, and if the PR is applied then letting 1 item should be reported as a bug IMO. Regards Goffi

Re: [Standards] Proposed XMPP Extension: Disco Feature Attachment

Le 2021-08-11 17:35, Jonas Schäfer a écrit : Hi goffi, Thanks for proposing this. The council has today vetoed the advancement for this ProtoXEP to Experimental, but I'd like to give you some feedback because I think the problem you're trying to address is real. The bottom of this email

Re: [Standards] Proposed XMPP Extension: Disco Feature Attachment

ent to mention it and to explain how exactly the feature is attached (e.g. what does it mean using Order-By with Pubsub, and how to use it). I would love to see feedbacks here, I think that the problem we are trying to solve is affecting a couple of XEPs and many people are concerned. Thanks Go

Re: [Standards] Council Minutes 2021-07-21

, the abstract is not the right one: it's "This specification provides a way to indicate that a feature is implemented for a specific namespace". Thanks for the quick minutes even during summer. Goffi ___ Standards mailing list Info: https://mail.jabber.o

[Standards] [XEP-0060] removing exception for last item when doing a node purge

o this fix. Thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

[Standards] Would it be possible to organize a regular review of PRs needing council/board decision?

n be unblock the currently concerned PRs? Thanks! Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Reverse ordering in XEP-0413 vs. XEP-0313's flipped pages

I've just published a new version of the XEP (with a namespace bump), I think I've addressed all feedbacks (yours and older ones), I've added a full Pubusb with RSM example and some direction for SQL based implementations. Let me know if you're happy with it, thanks. Goffi

Re: [Standards] Reverse ordering in XEP-0413 vs. XEP-0313's flipped pages

/xep-0060.html#subscriber-retrieve-returnsome ) Thanks for the feedbacks, I'll try to update it this week. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] XEP Wishlist: Encrypted Information Storage

publish a blog post with more details, and of course I'll reach standard@ in time to discuss that. And yeah, this will open the doors to many, many interesting things. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards

Re: [Standards] Slummit 2021 - Tales

e for any XMPP dev, admin, or even user. That's it but there is more (see my blog for details). The project website is at https://salut-a-toi.org (the website will probably move to libervia.org at some point, but this address will still work). If you have any question, I'm available here o

Re: [Standards] Announcing Slummit 2021

to be sure that it is still happening. Thanks! Goffi P.S.: this should be probably on summit@ mailing list, but the original thread was here. Le 2021-01-30 17:12, Tedd Sterr a écrit : Due to forseen circumstances, this will be postponed until 20-21 February. I was trying to fit it into what would

Re: [Standards] Announcing Slummit 2021

be of course Jitsi Meet, depending of number of attendees. I can write also a paragraph about what I'm working on, and would be interested to do a short talk too. Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo

Re: [Standards] LAST CALL: XEP-0393 (Message Styling)

Le 2020-05-25 15:01, Tedd Sterr a écrit : But there is no way to know if the text is formatted or not, there is no marker, discovery, or anything to indicate that styling syntax is used. The assumption is that styling is always present and enabled, and so it's always applied to all text -

Re: [Standards] LAST CALL: XEP-0393 (Message Styling)

Your feedback is appreciated! Thanks for the work done, but I'm really concerned with this specific extensions, and I think that a proper discovery/flagging mechanism would be the bare minimum to make it usable (but even with that, I'm more in favor of a proper separation of formatting and meaningfu

Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)

tooltips in the rendered XEP, that would avoid to go down and up just to read them. I hope this will be useful Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] XMPP Compliance Badges, prototype feedback requested.

0277. It's a category that we are improving a lot, and a badge would help potential user to see which client support that. Too late for 2019 suite, but would be nice to think about it for 2020. Thanks for the work to all people involved. Regards Goffi

Re: [Standards] Files encryption and OMEMO/OX

Le 2019-03-29 18:24, Jonas Schäfer a écrit : On Freitag, 22. März 2019 08:43:01 CET goffi wrote: Hello, about a year ago, Daniel's proposition to encrypt files with OMEMO has been rejected (proposal: https://xmpp.org/extensions/inbox/omemo-media-sharing.html, council rejection: https

[Standards] Files encryption and OMEMO/OX

is working on some alternative (which would ideally work with OMEMO and OX)? Also note that at least Conversations and Gajim use this non standard aesgcm scheme, which is causing compatibility issues for other clients. thanks Goffi ___ Standards

Re: [Standards] XMPP Council Minutes 2019-01-16

nce of the XEP. The ML discussion has shown that this is a > hot and complex topic, and I'm interested in seeing how it develops. > > > > Georg Thanks. I've promised an update but I'm currently overwhelmed with FOSDEM preparation, so I'm postponning that to afte

Re: [Standards] Tidying Deferred

to see back to experimental (in the case of experimental means "nobody cares", otherwise I don't mind that XEPs are in Deferred state). Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Tidying Deferred

ere should be a way to change/extend the authors after some time (for instance edhelas or me could work on the XEP-0277). For the later case, Deferred is a state that is OK for me, but I would not see the XEPs being killed (it's usable and used), I'm letting them in this state on purpose for th

Re: [Standards] XMPP Council Minutes 2019-01-09

change that while others are still on-list) For the record, I've answered to the concerns raised by the council at https://mail.jabber.org/pipermail/standards/2019-January/035646.html . I hope this helps. Thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Proposed XMPP Extension: Order-By

Le dimanche 13 janvier 2019, 12:53:51 CET Evgeny a écrit : > On Sun, Jan 13, 2019 at 2:40 PM, Goffi wrote: > > Future XEPs may extend this, but in case where it's too complicated, > > implementation has always the choice to not implement it, or to have > > different fe

Re: [Standards] Proposed XMPP Extension: Order-By

Le dimanche 13 janvier 2019, 12:28:09 CET Evgeny a écrit : > On Sun, Jan 13, 2019 at 2:16 PM, Goffi wrote: > > For Pubsub services based on SQL or NoSQL databases, it should not be > > too hard to implement as ordering is most of time a part of API. > > Note however, that

Re: [Standards] Proposed XMPP Extension: Order-By

Le dimanche 13 janvier 2019, 12:24:45 CET Evgeny a écrit : > On Sun, Jan 13, 2019 at 2:16 PM, Goffi wrote: > > a XEP for XPATH like syntax > > And the server will process this XPATH query? > Not sure if you're serious... This is a future plan, not concerning th

Re: [Standards] Proposed XMPP Extension: Order-By

d item, nothing fancy. That's it, I hope I have convinced you. Anyway this is experimental, time will show where it goes. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Proposed XMPP Extension: Order-By

other XEP for that. If I can find some time today (I'm overwhelmed, so it's not sure at all), I'll try to update the protoXEP with all the insightful feebacks I've had sor far. Thank you all for those comments :) ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Proposed XMPP Extension: Order-By

Le lundi 7 janvier 2019, 21:00:42 CET Evgeny a écrit : > On Mon, Jan 7, 2019 at 8:28 PM, Goffi wrote: > > Are you talking about the fact that "date of modification" (as > > defined in the protoXEP) could be out of sync between clusters? > > No, from the discus

Re: [Standards] Proposed XMPP Extension: Order-By

nd up with a simple list of items. > - In contrast to what Philipp thinks, I think that using multiple > elements (and having their relative order be significant) is fine; As goffi > mentions, pubsub itself is a valid precedent for that, and I think even a > XEP-0004 needs to be able t

Re: [Standards] Proposed XMPP Extension: Order-By

Hi Evgeny, Le lundi 7 janvier 2019, 09:30:26 CET Evgeny a écrit : > On Mon, Jan 7, 2019 at 10:44 AM, Goffi wrote: > > Is there any implementation in the wild which would have issue with > > node order? > > Sure, any clustered database will have issues with > su

Re: [Standards] Proposed XMPP Extension: Order-By

ult thing to do, but it doesn't seem needed. Is there any implementation in the wild which would have issue with node order? When you get the result of a pubsub get query, the order of items is also significant. ++ Goffi ___ Standards mailing list Inf

Re: [Standards] Proposed XMPP Extension: Order-By

; Unsubscribe: standards-unsubscr...@xmpp.org > ___ > Just a precision because after talking on xsf@ it doesn't seem clear: the order affect the whole archive, not just a result set, pretty much like ORDER BY in SQL. I'll cla

Re: [Standards] XEP-0060: Item ordering

uot;. It seems logical to me too, but this is a problem in several use cases (blogging, or experimental features I'm working on like tickets). To fix this, I've just submitted a new XEP, "Order-By", that changes the business logic. It should be easy to implement client a

Re: [Standards] Server status pages

nsubscribe: standards-unsubscr...@xmpp.org > ___ > Hi, That's a great idea. Not sure about XEP-0157, but if nothing better arise, why not. In addition to status page, it would be great to have a way to get future planed maintenance (at least the

Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items

lacing current one, and in the case of OMEMO bundles, this can quickly grow. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items

Le vendredi 27 juillet 2018, 19:21:22 CEST Goffi a écrit : > An (animated) picture worth thousand words :) > > https://repos.goffi.org/sat_docs/raw-file/tip/screenshots/0.7/ > language_filtering.gif > > The experimental language detection put aside, I'm using xml:lang

Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items

Le vendredi 27 juillet 2018, 17:24:27 CEST Peter Saint-Andre a écrit : > On 7/27/18 8:03 AM, Goffi wrote: > > Hello, > > > > I'm currently working on OMEMO implementation in Salut à Toi thanks to > > the work of Syndace (https://github.com/Syndace/python-omemo)

Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items

is the case), it should be indicated in the XEP-0384 in my opinion. > So my question would be, how do you get into a situation where a server > sends you all items of the Node? It's not in my notifications, I'm checking manually the content of my PEP nodes t

[Standards] [XEP-0384] OMEMO: xml:lang + max_items

, thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] XMPP Council Minutes 2018-06-20

returned by servers, in the same way as size limit can be returned. It would be even better to be able to list existing files and delete them on request, but this can be done in a separated XEP. Thanks Goffi Le samedi 23 juin 2018, 18:08:32 CEST Goffi a écrit : > Did you read my feedback ab

Re: [Standards] XMPP Council Minutes 2018-06-20

Dave: [pending] > Georg: [pending] Did you read my feedback about this? In particular what about my remarks on expiration date? I would like to have an answer on that, it's particularly important in my opinion. Thanks! Cheers Goffi ___ Standards

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

d spec is well explained. additional notes: - there is no validation schema in section 11 - there is no short name ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Thoughts on MIX adoption (and will MIX ever happen?)

nsible consider when > and if this will change. > [SNIP] Interested in implementing MIX in SàT, but not a priority (and lacking resources). We have already blogging, comments, shared files and pictures based on pubsub/jingle. Goffi ___ Standa

Re: [Standards] XEP-0394: too weak to replace XEP-0071

people (developers and users). Cheers Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Call for Experience: XEP-0048: Bookmarks

keywords, hierarchy, or anything else. We have been thinking for a while with Edhelas about writting an alternative proposal for bookmaks actually, but that's an other topic. Goffi Le mercredi 7 mars 2018, 20:17:24 CET Jonas Wielicki a écrit : > The XEP Editor would like to Call for Experie

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

ally find the idea really good, it's a clean separation between content and style, which means that there is not need to send a text version as we have too with XHTML-IM. XEP-0393 on the other hand is totally mixing style and content, that's why I really dislike i

Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing

ned by XEP-0329 potentially big. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing

files and/or a lot of files. Using path or UUID would be a good solution, but we need to be able to specify them in XEP-0234 (either by allowing "/" in name, or by using an other element). Goffi ___ Standards mailing list Info: https:/

Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing

only the filename or the hash (even if payload will be the same with single hash, metadata like name or date can differ) > The XEP hints at the possibility of requesting a file by name only (sans > path), but only when this will be unique; I suggest the request MUST > include the path

Re: [Standards] [XEP-0264] thumbnails: we should be able to transmit them with XEP-0234

Le samedi 24 février 2018, 18:25:26 CET Kim Alvefur a écrit : > On Sat, Feb 24, 2018 at 09:12:30AM +0100, Goffi wrote: > > currently thumbnails are transmitted using http(s) or BoB (XEP-0231). > > But with resolutions we can have todays even on small screens, size of > &

Re: [Standards] [XEP-0264] thumbnails: we should be able to transmit them with XEP-0234

Le samedi 24 février 2018, 18:25:26 CET Kim Alvefur a écrit : > On Sat, Feb 24, 2018 at 09:12:30AM +0100, Goffi wrote: > > currently thumbnails are transmitted using http(s) or BoB (XEP-0231). > > But with resolutions we can have todays even on small screens, size of > &

[Standards] [XEP-0264] thumbnails: we should be able to transmit them with XEP-0234

, so http is not an option here. As XEP-0234 is able to transmit several files in the same session, it would be a good candidate for that. Doesn anybody see an issue with using XEP-0234 for that? If no I'll propose the change on the XEP. Goffi

Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing

Le vendredi 23 février 2018, 10:16:49 CET Goffi a écrit : > Le vendredi 23 février 2018, 10:02:15 CET Jonas Wielicki a écrit : > > On Freitag, 23. Februar 2018 09:47:00 CET Goffi wrote: > > > 1) XEP-0234 is in Last Call which is supposed to be finished, what > >

Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing

Le vendredi 23 février 2018, 10:02:15 CET Jonas Wielicki a écrit : > On Freitag, 23. Februar 2018 09:47:00 CET Goffi wrote: > > 1) XEP-0234 is in Last Call which is supposed to be finished, what the > > status about that? > > The Council vote isn’t over yet (but fr

[Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing

) Beside that this XEP is really usable. Thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] undefined state in XEP-0050

, so your proposition seems a reasonable fix. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

[Standards] feedback on file sharing with XMPP [XEP-0135] [XEP-0214] [XEP-0234] [XEP-0329]

on this field, please contact me. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Council Agenda 2018-02-14

Le mardi 13 février 2018, 18:28:02 CET Dave Cridland a écrit : > As such, I'm thinking of writing something for XEP-0001 that imposes a > last-call-like period for comments - Intent To Deprecate/Obsolete > perhaps - and imposing that on ourselves. That's a really good idea! > Dave.

Re: [Standards] Adding logo to MUC and PubSub node

otification mecanism for config options, as notification may be useful not only for avatar/icon. We could use the same sementic as for nodes, but with a different namespace. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/s

Re: [Standards] XMPP Council Minutes, 2018-01-17

Le jeudi 18 janvier 2018, 11:36:22 CET Daniel Gultsch a écrit : > 2018-01-18 11:07 GMT+01:00 Goffi <go...@goffi.org>: > > Hello everybody, > > > > Le jeudi 18 janvier 2018, 09:28:33 CET Dave Cridland a écrit : > > > 6) https://github.com/xsf/xeps/pull/557

Re: [Standards] XMPP Council Minutes, 2018-01-17

r my point of view (as a matter of fact, I was actually present for this dissussion on this particular P.R., but other people where not). I take this P.R. as an example, but it's a general remark. Thanks Goffi ___ Standards mailing list Info: https://mail.

Re: [Standards] Proposed XMPP Extension: Styling

t; instead? At least this show this is not a good practice supported by the community. And please if it really do through the official number, add on "opt-in" mechanism as previously discussed (this is still not in the protoXEP). Thanks Goffi _

Re: [Standards] 2017-11-08 XSF Council Minutes

Le 2017-11-08 20:20, Jonas Wielicki a écrit : On Mittwoch, 8. November 2017 20:02:24 CET Goffi wrote: I was in favor of making formatting characters mandatory in styling, but if there is markup and attribute, I think it's not needed anymore. It is, for clients not supporting markup at all

Re: [Standards] 2017-11-08 XSF Council Minutes

tory in styling, but if there is markup and attribute, I think it's not needed anymore. And please don't use BHM, it's using markdown with all the issues I have already expressed + it's open to any formatting which is bad idea. Styling fixes those issues. Thanks Goffi

Re: [Standards] Proposed XMPP Extension: Styling

t fallback. I forgot to mention here: XHTML-IM is not sufficient for blogging, SàT and Movim use XHTML that we clean. I think in addition to current markup debate, we need a XEP for full XHTML implementation with security consideration, but that's a diffe

Re: [Standards] Proposed XMPP Extension: Styling

Le mercredi 8 novembre 2017, 11:18:51 CET Jonas Wielicki a écrit : > On Mittwoch, 8. November 2017 10:58:06 CET Goffi wrote: > We’re having a nice, civil discussion in xsf@ right now about this, let me > summarize my current viewpoint on this (as author of the Message Markup > pro

Re: [Standards] Proposed XMPP Extension: Styling

ense to keep pushing this styling one, the use case is covered and in a far better way (no markup in the body). Cheers Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Proposed XMPP Extension: Message Markup

Le mercredi 8 novembre 2017, 10:11:52 CET Jonas Wielicki a écrit : > On Mittwoch, 8. November 2017 08:29:49 CET Georg Lukas wrote: > > * Goffi <go...@goffi.org> [2017-11-08 08:17]: > > > about the stars in the list items, it's not really nice to keep them. > > >

Re: [Standards] Proposed XMPP Extension: Message Markup

an attribute to say which plain text characters can be safely removed without changing the meaning. For instance type="numeric" means than "^[0-9]+\)" can be removed, type="star" mean that the first character must be a "*" and it can be removed.

Re: [Standards] Proposed XMPP Extension: Message Markup

lient replace it by HTML tags without checking, it could lead to an open tag without the corresponding closing one. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Proposed XMPP Extension: Message Markup

nk it solves all my concerns, it's clean separation, extensible, easy to implement, not polluting the , and standardized. I'm all in favor of deprecating XHTML-IM is this one is accepted. Great work and thanks a lot ! Goffi P.-S.: it was really worthing having those debates, at

Re: [Standards] Proposed XMPP Extension: Styling

ion is useful for screen readers). That said, having a single message would not necessarily be a bad idea (I'm quite in favor of that actually), if it is correctly marked (which is not the case with current proposal). Cheers Goffi ___ Standards mail

Re: [Standards] Proposed XMPP Extension: Styling

Le mardi 7 novembre 2017, 13:02:40 CET Dave Cridland a écrit : > On 6 November 2017 at 22:58, Goffi <go...@goffi.org> wrote: > > As an exemple which could lead to big trouble, imagine a shell@ MUC room > > with> > > somebody pasting this code to explain something:

Re: [Standards] Proposed XMPP Extension: Styling

Le mardi 7 novembre 2017, 12:57:32 CET Dave Cridland a écrit : > On 6 November 2017 at 22:58, Goffi <go...@goffi.org> wrote: > > I still really dislike the fact that rendering of text body could be > > different accross clients. > > I don't follow why this is a problem,

Re: [Standards] Proposed XMPP Extension: Styling

ody could be different accross clients. On other important point mentionned by jnanar, is that formatting data in text could be a really bad thing for accessibility (thing about page readers). ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Proposed XMPP Extension: Styling

Le lundi 6 novembre 2017, 22:14:21 CET Daniel Gultsch a écrit : > 2017-11-06 22:06 GMT+01:00 Goffi <go...@goffi.org>: > > Le lundi 6 novembre 2017, 22:04:29 CET Daniel Gultsch a écrit : > >> 2017-11-06 21:58 GMT+01:00 Goffi <go...@goffi.org>: > >> > Le

Re: [Standards] Proposed XMPP Extension: Styling

Le lundi 6 novembre 2017, 22:04:29 CET Daniel Gultsch a écrit : > 2017-11-06 21:58 GMT+01:00 Goffi <go...@goffi.org>: > > Le lundi 6 novembre 2017, 21:53:48 CET Daniel Gultsch a écrit : > >> 2017-11-06 21:46 GMT+01:00 Goffi <go...@goffi.org>: > >> > And

Re: [Standards] Proposed XMPP Extension: Styling

Le lundi 6 novembre 2017, 21:53:48 CET Daniel Gultsch a écrit : > 2017-11-06 21:46 GMT+01:00 Goffi <go...@goffi.org>: > > And you have no indication of markup, so if I copy/paste some code for > > instance, some client will render it with markup, > > I think it is pos

Re: [Standards] Proposed XMPP Extension: Styling

scape the code, the markup aware client will render it correctly, but it will be wrong for all other clients. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Proposed XMPP Extension: Body Markup Hints

Le mercredi 18 octobre 2017, 20:38:47 CEST Sam Whited a écrit : > On Wed, Oct 18, 2017, at 12:40, Goffi wrote: > > If we base the debate on devs not really taking care of security (which > > was > > the initial issue with XHTML-IM) or path of less resistance, they will >

Re: [Standards] Proposed XMPP Extension: Body Markup Hints

Le mercredi 18 octobre 2017, 19:56:23 CEST Florian Schmaus a écrit : > On 18.10.2017 19:40, Goffi wrote: > > If you believe that clients operated by human users send BMH then please > read the very first post of mine on this thread. I think a lot of > confusion comes from

Re: [Standards] Proposed XMPP Extension: Body Markup Hints

Le mercredi 18 octobre 2017, 19:19:53 CEST Florian Schmaus a écrit : > On 18.10.2017 18:47, Goffi wrote: > > CommonMark is specified, but how can you garantee that the dev will use > > libraries compliant with CommonMark? > > No one can, but that applies to all appr

  1   2   3   >