from:"Kozlov Konstantin"

Hello! 15.03.2018, 18:30, "Ненахов Андрей" :Using markdown for text formatting is a bad idea.  Markdown is used as a simple means to give a semi-rich text formating where complex WISIWYG editors can't be used. Like, webpage contents editing in many CMSs. However, user always knows that if he styles text using markdown, it'll always be presented in rich text form. This isn't the case with XMPP messengers, where  user typically has just one field to enter message text. App has no way of knowing if user intended to be rich format text or not. Also, app has no way of knowing if it has to provide a plaintext version of message, and markdown version. It will likely result in app treating all messages as 'markdown' messages, and any unsupporting clients would get messages with ## --- etc. It'll also result in unwanted formatting if users will send each other portions of code or config files, commented out lines would be presented as headers, etc.  It can be avoided if sending user will get some form of control whether they want to have it processed with markdown or not (like a switch), but it'll complicate UX, and switching from plaintext to markdown is generally worse than switching from plaintext to WISIWYG interface employing some kind of rich editor to compose messages (like Gmail does, for example).  That's one of the lot of reasons I hate the idea of XEP-0393 from the beginning.IMHO using LML in messages is just a patch for ancient things from the last century like IRC or FIDO, which support plain text only.Modern XMPP, which uses XML with almost unlimited possibilities doesn't need such patches and crutches. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

Hello! 15.03.2018, 17:40, "Sam Whited" :Custom smileys should probably be its own XEP, but I agree we should make something for that at some point.Attatching images is better handled by XEP-0066 and does not need to be a part of a message formatting spec. It's likely that even if you don't support formatting you may want to include an image.Just forgot3. We already have XEP-0385 which suits much better for attaching images than XEP-0066. With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

Hello! 15.03.2018, 17:40, "Sam Whited" <s...@samwhited.com>:On Thu, Mar 15, 2018, at 02:22, Kozlov Konstantin wrote: 1. Embedding pics into messages: ~80%. Pics are used to display memes, as custom smilies, as parts congratulation cards, as small parts of screenshots to explain something and so on.Custom smileys should probably be its own XEP, but I agree we should make something for that at some point.Attatching images is better handled by XEP-0066 and does not need to be a part of a message formatting spec. It's likely that even if you don't support formatting you may want to include an image.I don't think XEP-0066 suits for attaching inmages.It provides no way to tell client softwarem that provided link contains image. So, client have to check every link to find out if there's an image on the other side.Even if I attach a link to image, that doesn't mean I want other party's client to display it within my message. I need a way to specify, if this image is to be attached to the message or just to be displayed as a link. 2. Striking out parts of text to make funny messages, like author wanted to insult other party say something else, but changed his/her mind: ~10% 3. Highlighting parts of text with *bold* (sometimes *italic* or _underscrore_), to add _expression_ or just attract attention to highlighted parts: ~5%These are supported, so nothing to do there.Right now we have just element whch sugested to be rendered either bold or italic. It's up to other party's client how to render it. I just want to be able to specify bold, italic or underlined explicitly. Otherwice I'll be unable to have WYSIWYG in my client, won't be sure what other party will see. 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's bad for users and bad for accessibility. There is a reason most modern messaging systems leave it out. If I have a black background and you send me messages with your text color set to black, I can no longer read it. If you set your font to be tiny and I'm hard of seeing, I can no longer read it. If you set it to be huge and I'm on my phone, it takes up half the screen and I'm annoyed. etc.That's mostly abuse. Most of the features of any client could be abused. You may send large meaningless messages, or you may annoy other party by sending him an Attention every 5 seconds or just sending him meaningless messages 2 times per second.A user should have a feature, and it's up to him how to use it. If he abuses font or color customization, other party will tell him not to do it or just ban him that or other way. 5. Sometimes used links[1] to make messages more compact.Links are great, feel free to automatically link URLs in your messages, I don't think we need a spec for this since most people do it already.Making text appear as links (without showing the link itself) is only a nice to have that seems like unnecessary complexity to me, but you could certainly write a spec to do it if it's something that you have a real use case for that can't be satisfied by auto linking URLs like most clients do already.Yes. Embebbed links are useful when link itself is too long and contains no useful information. I beleive that only human friendly content should be displayed in the message and the technical parts (like URLs) should be hidden.Attaching links via XEP-0066 solves the problem only partially. My client, for example displays link only if there's no element. If element present, it display it as a link.But often its much better to put link right where it mentioned in the message. It makes message more compact in makes it more comfortable to user to click on the link just where it sees it in the text without looking for it in the list of attached links below the message or somewhere else.And XEP-0071 was a good solution for this usecase. And I don't see the reason to invent specification for such a little thing, if we can easily put it into XEP-0394, making it the one to substitute XEP-0071. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

  15.03.2018, 16:31, "Jonas Wielicki" :Okay, so since I’m not going to get around to updating '394 this month andthere’s considerable interest, I’ll write down what I have in mind:* Emphasis, Strong emphasis, inline-preformatted (code)* Enumerations* Itemized lists* Headings (two or three levels)* Paragraphs* XEP-0392-based colors (i.e. you only give a hue and the remainder is handledby the recipient)* Code blocks with annotation of the language for optional receiver-sidehighlighting* Maybe inline imagesIt sounds promising. I just wonder why no links and no font customization?Now there has been a lot of discussion around how to make this degradegracefully. I’m thinking of the following:Each markup annotation has a mandatory pre- and postfix in the body which isstripped once the markup is applied. That works like this (just a roughoutline, don’t take the syntax for literal):This is the *new* markup.  Now  would be defined so that the selected range of  MUSTstart with "*" and MUST end with "*". If-and-only-if (iff) that is the case,the prefix and postfix is removed and the text is displayed with emphasisapplied on the word "new".This is complex, and will not get less complex with more complex constructslike enumerations.The reason for this complexity is that it allows a '393-compatible message, and also in general a good human-readable representation in clientswhich do not support it (if we chose the requirements well), while at the sametime not allowing to "delete" arbitrary characters for some readers (it hasbeen pointed out that this type of discrepancy can lead to problems).That idea is really interesting. An attempt to add compatibility to those two XEP's.But implementation  element like this without additional statements implies support of XEP-0393.IMHO it should be stated, that  element should be allowed only if other party explicitly supports not only XEP-0394, but also XEP-0393. Otherwise, it would be impossible to implement XEP-0394 without implementing XEP-0393, and XEP-0394 will be just an addition to XEP-0393. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

Hello! 15.03.2018, 13:33, "W. Martin Borgert" <deba...@debian.org>:On 2018-03-15 10:22, Kozlov Konstantin wrote: I don't want to discuss XEP-0393, 'cause the whole idea of using LML in IM sounds bad. Flaws if it is obvious, so it's needless to mention them again.I disagree. Yes it is ugly, but having a widely used LML, suchas Markdown (in contrast to some strange homebrew) in XMPP wouldbe a pragmatic approach, IMVHO.Many people know Markdown syntax nowadays, there are parsers forit in many different programming languages, and we already knowhow ugly and illogical it is. Just needs a new XEP :~)I'm not sure about Makrdown, but I beleive that the only reason why we need XEP-0393 is to describe all current implementations of markup in existing clients, declare it Historical, then deprecate. To let authors of such clients know that LML is not a good way to implement rich text formatting in IM. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

Hello!The problem of XEP-0393 is that markup mixed with plain text and it's hard to purge it from it.With XEP-0393 client MUST support XEP-0393 to get plain text without formatting. So using XEP-0393 with XEP-0394 together is useless:Client which supports XEP-0394 only will display formatted text with a lot of garbage, making it hard to read, 'cause XEP-0394 provides no way to specify parts of text to ignore while rendering.15.03.2018, 13:51, "Evgeny Khramtsov" :Thu, 15 Mar 2018 11:31:37 +0100"W. Martin Borgert"  wrote:  Many people know Markdown syntax nowadays, there are parsers for it in many different programming languages, and we already know how ugly and illogical it is. Just needs a new XEP :~)From what I understand you can use markdown with that another XEP: e.g.you can use `foobar` in the text and the client software will addcorresponding markup elements from that another XEP.With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

Hello! Powerful XEP-0071, implemented in many clients is deprecated now.I guess, It's time to think about substitution it with another one. As I mentioned before, there is no XEP, which can substitute it right now.We have XEP-0393 and XEP-0394, whch potentially can provide functionality of XEP-0071, but not in their current state.I don't want to discuss XEP-0393, 'cause the whole idea of using LML in IM sounds bad. Flaws if it is obvious, so it's needless to mention them again.As for XEP-0394, I already said before, that the whole idea is interesting, but right now it has a lot of limitations to substitute even basic functionality of XEP-0071. So, if I decide to implement XEP-0394 instead of XEP-0071 in my client, it will be hard to explain users, why in new versions most of rich text formatting functionality is gone. According to my UX, XEP-0071 functionality mostly used for: Embedding pics into messages: ~80%. Pics are used to display memes, as custom smilies, as parts congratulation cards, as small parts of screenshots to explain something and so on.Striking out parts of text to make funny messages, like author wanted to insult other party say something else, but changed his/her mind: ~10%Highlighting parts of text with bold (sometimes italic or underscrore), to add _expression_ or just attract attention to highlighted parts: ~5%Using different fonts, font sizes and colors, for the same as in 3 or as parts of congratulation cards: ~3%.Sometimes used links to make messages more compact.Almost never used block formatting (headings, lists and so on). Unfortunately, in XEP-0394 in its current state most of mostly used features of XEP-0071 are not implemented.So, I'd like to discuss implementation of those features in XEP-0394, while it is still EXPERIMENTAL and not widely implemented.How do you feel about it? With my best regards,Konstantin P. S.: XEP-0066 and XEP-0385 may be used to attach links and images to message, but attaching them do not cover all the use cases of embedding.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0122: Data Forms Validation

2018-03-14 Thread Kozlov Konstantin

14.03.2018, 20:30, "Jonas Wielicki (XSF Editor)" :The XEP Editor would like to Call for Experience with XEP-0122 beforepresenting it to the Council for advancing it to Final status.During the Call for Experience, please answer the following questions:1. What software has XEP-0122 implemented? Please note that theprotocol must be implemented in at least two separate codebases (atleast one of which must be free or open-source software) in order toadvance from Draft to Final.At least in eyeCU and Vacuum-IM.2. Have developers experienced any problems with the protocol asdefined in XEP-0122? If so, please describe the problems and, ifpossible, suggested solutions.No.3. Is the text of XEP-0122 clear and unambiguous? Are more examplesneeded? Is the conformance language (MAY/SHOULD/MUST) appropriate?Have developers found the text confusing at all? Please describe anysuggestions you have for improving the text.Yes. Everything is clear.If you have any comments about advancing XEP-0122 from Draft to Final,please provide them by the close of business on 2018-03-28. After theCall for Experience, this XEP might undergo revisions to addressfeedback received, after which it will be presented to the XMPPCouncil for voting to a status of Final.No comments right now.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0092: Software Version

2018-03-14 Thread Kozlov Konstantin

14.03.2018, 20:30, "Jonas Wielicki (XSF Editor)" :The XEP Editor would like to Call for Experience with XEP-0092 beforepresenting it to the Council for advancing it to Final status.During the Call for Experience, please answer the following questions:1. What software has XEP-0092 implemented? Please note that theprotocol must be implemented in at least two separate codebases (atleast one of which must be free or open-source software) in order toadvance from Draft to Final.At least in eyeCU and Vacuum-IM.2. Have developers experienced any problems with the protocol asdefined in XEP-0092? If so, please describe the problems and, ifpossible, suggested solutions.No3. Is the text of XEP-0092 clear and unambiguous? Are more examplesneeded? Is the conformance language (MAY/SHOULD/MUST) appropriate?Have developers found the text confusing at all? Please describe anysuggestions you have for improving the text.Yes. Everything is all right.If you have any comments about advancing XEP-0092 from Draft to Final,please provide them by the close of business on 2018-03-28. After theCall for Experience, this XEP might undergo revisions to addressfeedback received, after which it will be presented to the XMPPCouncil for voting to a status of Final.No comments right now.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0393 and XEP-0394 naming

Hello! I just want to clarify my thoughts about naming. Why do I think that "Markup" more suits for XEP-0393 and "Styling" for XEP-0394.Well known markup languages like HTML (HyperText Markup Language) and XML (eXtensible Markup Language) have markup elements mixed with text blocks to display. And syntax, which used by XEP-0393 is just a Lightweight markup language (LML) according to Wikipedia. On the other hand, when it comes to styles, we may remember CSS (Cascading Style Sheets). With CSS styles and text are separated. Styles, described in CSS are applied to the text. XEP-0394 provides similar technology: styles, described in  element of  stanza applied to unstyled text in message body, "styling" it.So, while XEP-0394 is EXPERIMENTAL and not widely implemented, I think it's a good idea to rename it to "styling" or something style-related, rename  element to  or  and change its namespace to "urn:xmpp:markup:0". And about "Message" part... Yes, I'm sure it should be changed to "Text", because in both XEP's only text part of the  stanza is affected, not the whole . With my best regards,Konstantin 08.03.2018, 21:18, "Tedd Sterr" <teddst...@outlook.com>: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 <standards-boun...@xmpp.org> on behalf of Sam Whited <s...@samwhited.com>Sent: 08 March 2018 16:35To: standards@xmpp.orgSubject: Re: [Standards] XEP-0393 and XEP-0394 naming On Thu, Mar 8, 2018, at 10:26, Kozlov Konstantin wrote:> Yes, maybe. It was just an example.Indeed. I'm okay with renaming if others agree that "styling" is confusing for some reason, but only if someone comes up with a name that expresses the intent clearer."Message Markup", or "Lightweight Message Markup" maybe? It's a bit of a mouthful.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0393 and XEP-0394 naming

Hello! 08.03.2018, 19:24, "Sam Whited" <s...@samwhited.com>:On Thu, Mar 8, 2018, at 10:18, Kozlov Konstantin wrote: For example we may rename XEP-0393 to "Markdown" 'cause its syntax somewhat similar to Markdown[1] language.That seems even more confusing than the other suggestion, because we'd be naming it "markdown" even though it's not markdown (or even compatible with markdown). :)Yes, maybe. It was just an example. With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0393 and XEP-0394 naming

Hello! 08.03.2018, 19:20, "Dave Cridland" <d...@cridland.net>:On 8 March 2018 at 16:18, Kozlov Konstantin <yag...@yandex.ru> wrote: The XEPs are not so widely implemented for the moment to care much about it.Actually, I think XEP-0393 has several implementations in widelydeployed clients.Yeah, sure. But I think, both developers and end-users do not much care about names of implemented XEPs. End-user do care about features they have and developers usually operate with XEP numbers and namespaces. With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0393 and XEP-0394 naming

Hello! 08.03.2018, 19:03, "Sam Whited" <s...@samwhited.com>:On Thu, Mar 8, 2018, at 10:01, Kozlov Konstantin wrote: I think "Markup" more suits for XEP-0393 and "Styling" for XEP-0394.I guess, we should think about renaming those XEPs to make their names less confusing.I'm not against this (as the author of 0393) if people find this confusing, but swapping the names seems even more confusing to me.The XEPs are not so widely implemented for the moment to care much about it.Anyway, we can just give new, less confusing names for both XEPs.For example we may rename XEP-0393 to "Markdown" 'cause its syntax somewhat similar to Markdown language. With my best regards,Konstantin 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0393 and XEP-0394 naming

Hello! Discussing XEP-0393 and XEP-0394 I mixed them up a few times. That's because their names are really confusing. I think "Markup" more suits for XEP-0393 and "Styling" for XEP-0394.I guess, we should think about renaming those XEPs to make their names less confusing. With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

Hello! 08.03.2018, 14:15, "Jonas Wielicki" <jo...@wielicki.name>:On Donnerstag, 8. März 2018 10:38:55 CET Kozlov Konstantin wrote: Hello! 08.03.2018, 12:18, "Dave Cridland" <d...@cridland.net>: The personal choice of Council was to deprecate XHTML-IM based on these facts. The previous Council decided to ensure there were alternates for XHTML-IM use-cases instead of deprecating.This was an editors mistake. The Council voted to Deprecate, not to Obsolete.I rectified the issue and I’m going to send out an email when the update islive on the website. Thanks for bringing this up and sorry for theinconvenience.In that case it's all right. While XEP is deprecated, I may keep develop its implementation until XEP-0394 become pwerful enogh to substitute it. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

Hello! 07.03.2018, 22:18, "Jonas Wielicki (XSF Editor)" :The XEP Editor would like to Call for Experience with XEP-0048 beforepresenting it to the Council for advancing it to Final status.During the Call for Experience, please answer the following questions:1. What software has XEP-0048 implemented? Please note that theprotocol must be implemented in at least two separate codebases (atleast one of which must be free or open-source software) in order toadvance from Draft to Final.It is implemented in eyeCU and Vacuum-IM. Both of them have the same codebse.2. Have developers experienced any problems with the protocol asdefined in XEP-0048? If so, please describe the problems and, ifpossible, suggested solutions.I'm not the author of implementation, but I just contacted the author and he said that there were no problem with implementation.3. Is the text of XEP-0048 clear and unambiguous? Are more examplesneeded? Is the conformance language (MAY/SHOULD/MUST) appropriate?Have developers found the text confusing at all? Please describe anysuggestions you have for improving the text.No. Everything is all right.If you have any comments about advancing XEP-0048 from Draft to Final,please provide them by the close of business on 2018-03-21. After theCall for Experience, this XEP might undergo revisions to addressfeedback received, after which it will be presented to the XMPPCouncil for voting to a status of Final.With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

Hello! 08.03.2018, 12:58, "Goffi" <go...@goffi.org>:Le mercredi 7 mars 2018, 19:21:45 CET Kozlov Konstantin a écrit :  Thank you for your reply. Yes, I know about those two. As for XEP-0394, I feel so bad the XEP idea, so I don't even want to discuss the XEP itself.Out of curiousity, what do you dislike in this XEP? I actually find the ideareally good, it's a clean separation between content and style, which meansthat 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 whyI really dislike it.I'm really sorry.  I mixed up those two. The name of those XEPs (Markup and Styling) are confusing me.So, I really dislike XEP-0393 and I find XEP-0394 interesting and worth further development. Sorry once again for confusing other subscribers of this mailing list. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

Hello! 08.03.2018, 12:18, "Dave Cridland" :The personal choice of Council was to deprecate XHTML-IM based onthese facts. The previous Council decided to ensure there werealternates for XHTML-IM use-cases instead of deprecating.Deprecating is not a serious problem. The probleb is that they are obsoleted if instead of deprecating. And that sounds really bad. With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

Hello! 08.03.2018, 10:52, "Jonas Wielicki" :In contrast to XML, XHTML-IM is a custom thing which needs to be re-implemented in ~every client. Well-known XML libraries exist for mostlanguages (even if they only FFI to libxml2 or libexpat).According to my experience, building a XHTML processor using an existing XML parser is a trivial task. It doesn't took a lot of time for me to build such processor using QtXML/QDomDocument framework. With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0066: Out of Band Data

Hello! 07.03.2018, 22:18, "Jonas Wielicki (XSF Editor)" :The XEP Editor would like to Call for Experience with XEP-0066 beforepresenting it to the Council for advancing it to Final status.During the Call for Experience, please answer the following questions:1. What software has XEP-0066 implemented? Please note that theprotocol must be implemented in at least two separate codebases (atleast one of which must be free or open-source software) in order toadvance from Draft to Final.It is implemented (partially) in eyeCU and Vacuum-IM. Both clients have the same codebase. Also, it is implemented in MRIM transport.2. Have developers experienced any problems with the protocol asdefined in XEP-0066? If so, please describe the problems and, ifpossible, suggested solutions.In Qt version of eyeCU I implemented only attaching URLs to messages right now. The same story with Vacuum-IM. Other usages of OOB is not implemented yet, but I plan to imlement them later.J2ME version of eyeCU allowed to send URLs via stanza and control download, but it is abandoned right now.I experienced no problem implementing those features.The only suggestion is to provide mechanism to notify other party of download progress (not only of the fact, that file was downloaded).3. Is the text of XEP-0066 clear and unambiguous? Are more examplesneeded? Is the conformance language (MAY/SHOULD/MUST) appropriate?Have developers found the text confusing at all? Please describe anysuggestions you have for improving the text.Yes. Everything is all right.If you have any comments about advancing XEP-0066 from Draft to Final,please provide them by the close of business on 2018-03-21. After theCall for Experience, this XEP might undergo revisions to addressfeedback received, after which it will be presented to the XMPPCouncil for voting to a status of Final. With my best regards,KonstantinYou can review the specification here:https://xmpp.org/extensions/xep-0066.htmlPlease send all feedback to the standards@xmpp.org discussion list.___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org__
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

Hello! 07.03.2018, 19:19, "Guus der Kinderen" :Primarily due to security concerns. There's a lot of discussion available in the mail archive. This is a good place to start: https://mail.jabber.org/pipermail/standards/2017-October/033546.html Thank you! I just read the message. I never thought that there are implementations of the XEP, which allow to execute scripts.I'm sure my implementaion do not.So, the only reason to obsolete the XEP is not the XEP itself, but bad implementations? With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

Hello! 07.03.2018, 21:20, "Jonas Wielicki" :As for an replacement, it depends on your use-case. There’s [XEP-0393](Message Styling) which should cover many IM use-cases. I started to work on[XEP-0394] (Message Markup) which intends to do a bit more, with a moreflexible approach. Note that I intend to overhaul XEP-0394 and I don’t know ofany implementations. XEP-0393 is implemented in a few clients already (I knowof Conversations and yaxim).kind regards,Jonas   [1]: https://mail.jabber.org/pipermail/standards/2017-October/033546.html   [2]: https://mail.jabber.org/pipermail/standards/2017-October/033596.html   [3]: https://mail.jabber.org/pipermail/standards/2017-October/033702.html   [4]: https://mail.jabber.org/pipermail/standards/2018-February/034302.html   [5]: http://logs.xmpp.org/council/2018-02-14/#16:03:14Thanx, I'll investigate those discussions. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

Hello! 07.03.2018, 19:18, "Jonas Wielicki" <jo...@wielicki.name>:On 7 March 2018 17:13:26 CET, Kozlov Konstantin <yag...@yandex.ru> wrote:___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org___cf. https://github.com/xsf/xeps/pull/594#issuecomment-369839060Thank you for your reply. Yes, I know about those two. As for XEP-0394, I feel so bad the XEP idea, so I don't even want to discuss the XEP itself.As for XEP-0393, yes, I feel it really interesting, but... see my reply to Sam. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

 Hello! 07.03.2018, 19:55, "Sam Whited" <s...@samwhited.com>:On Wed, Mar 7, 2018, at 10:13, Kozlov Konstantin wrote: Yes, this XEP has its disadvantages, but almos all of modern clients do implement it and there is no XEP right now, which can substitute it.TL;DR — almost all of modern clients that implement it implement it in an insecure manner (which is not the XEPs fault, but it is apparently hard for developers to implement it correctly, especially in web clients in my experience).Thank you for your reply. Unfortunately, I missed the discussions about security issues in XHTML-IM implementations. So, please give me the link to overview of such issues if it exists. As a devoleper of a client whish imlements the XEP, I wonder if my implementation also have such issues.For most clients, https://xmpp.org/extensions/xep-0393.html serves as a good enough replacement (especially when paired with https://xmpp.org/extensions/xep-0066.html or https://xmpp.org/extensions/xep-0385.html for media).For clients where that is not good enough they won't drop XHTML-IM support over night and we can have a discussion about how to support them if and when they come forward.As for XEP-0393, as I said before, it's really interesting but it has some weak points and I guess we need to start discussing the way fill the gaps, before a lot of implementations appeared.The most important things IMHO is lack of links and embedded images. You may attach links to message with XEP-0066, but thats not it. Sometimes it's much better when parts if text are clickable, so the message is not overloaded with redundant information.About embedded images... As a developer of an XMPP client, I have some UX of my app for some years and according to it, 90% of using XHTML-IM is embedding images into messages. Of course, XEP-0385 allows to send an image in a separate message, but embedding images into text is more flexible and allows user to compose more fancy messages to express their ideas better.And the second weak point is duplicated markers in lists. I'm sure extra markers should be removed anyhow. I have some ideas how to develop XEP-0393 to implement embedded images and links and how to remove markers from the list. If anyone's interested, let's discuss them. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

I wonder, why this one was obsoleted?Yes, this XEP has its disadvantages, but almos all of modern clients do implement it and there is no XEP right now, which can substitute it. 28.02.2018, 21:24, "Jonas Wielicki (XSF Editor)" :Version 1.5.3 of XEP-0071 (XHTML-IM) has been released.Abstract:This specification defines an XHTML 1.0 Integration Set for use inexchanging instant messages that contain lightweight text markup. Theprotocol enables an XMPP entity to format a message using a smallrange of commonly-used HTML elements, attributes, and style propertiesthat are suitable for use in instant messaging. The protocol alsoexcludes HTML constructs that may introduce malware and othervulnerabilities (such as scripts and objects) for improved security.Changelog:Per a vote of the XMPP Council, advanced to Obsolete. (XEP Editor(ssw))URL: https://xmpp.org/extensions/xep-0071.htmlNote: The information in the XEP list at https://xmpp.org/extensions/is updated by a separate automated process and may be stale at thetime this email is sent. The XEP documents linked herein are up-to-date.___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org__
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

2017-11-26 Thread Kozlov Konstantin

  24.11.2017, 18:36, "Matthew Wild" :On 19 November 2017 at 16:54, Konstantin Kozlov  wrote: The main problem I see so far is inability to determine for which dates message archive is available without reading the whole archive. Author of Vacuum IM (which is an upstream of my client) tried to implement XEP-0313 instead of XEP-0136, but gave up because of lack of such functionality.I don't think that makes the XEP "too raw", as you wrote in yourprevious email. I think this functionality is out of the scope ofXEP-0313. There is no reason it could not be done in an additional XEPthough, as a different kind of operation on the same archive.  Vacuum IM has very convenient interface to manage history and he don't want to break it.Well, XEP-0313 intentionally does not try to replicate all thefeatures of XEP-0136. If XEP-0136 is better suited, then it stillexists for those use-cases.Noone says about replicating the whole XEP under new name, but ability to discover archive contents seems to be basic for any archive management.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

2017-11-20 Thread Kozlov Konstantin

Styling. Looks like I've got something mixed up.20.11.2017, 21:28, "Evgeny Khramtsov" :Mon, 20 Nov 2017 21:34:52 +0500Konstantin Kozlov  wrote: It's too bad you didn't use your veto against that awful proto.Which proto do you mean?___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

2017-11-20 Thread Kozlov Konstantin

I was talking about "Styling" only. "Markup" is an interesting thing, but I think it's too weak right now. At least image embedding needs to be added to make it possible to replace XEP-0071 with it.20.11.2017, 19:58, "Dave Cridland" :On 20 November 2017 at 16:34, Konstantin Kozlov  wrote: It's too bad you didn't use your veto against that awful proto. It don't even worth to waste XEP number for things like this one.Wait - which one did you want us to veto? Both? Neither?___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org__
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0136: Message Archiving moved to Deprecated

2017-11-16 Thread Kozlov Konstantin

It's a nice idea to recommend experimental XEP's.16.11.2017, 11:45, "Evgeny Khramtsov" :Thu, 16 Nov 2017 11:42:58 +0300Kozlov Konstantin  wrote: Bad thing is that developers of new clents don't know which XEP to implement. XEP-0136 (which is deprecated) or XEP-0313 (which is still experimental and may be deferred, retracted and so on).MAM is recommended by the compliance suite.___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org__
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0136: Message Archiving moved to Deprecated

2017-11-16 Thread Kozlov Konstantin

Bad thing is that developers of new clents don't know which XEP to implement.XEP-0136 (which is deprecated) or XEP-0313 (which is still experimental and may be deferred, retracted and so on).16.11.2017, 11:12, "Dave Cridland" <d...@cridland.net>:On 16 Nov 2017 7:43 am, "Kozlov Konstantin" <yag...@yandex.ru> wrote:Too bad...XEP-0313 is still experimental and XEP-0136 is deprecated already.No, it's a good thing. While MAM isn't quite Draft yet, the council was confident it will be very soon, and is clearly what we want new implementations to be doing.Deprecated didn't mean that people must not implement, and certainly not that they must remove existing code - it means that we don't think a new client or server should go that route today.16.11.2017, 00:25, "Sam Whited" <s...@samwhited.com>:Hi all,This email is to let you know that XEP-0136: Message Archiving [1] hasbeen moved to a stats of Deprecated per a vote of the Council. The newversion will be published and live on the website soon.—Sam[1]: https://xmpp.org/extensions/xep-0136.html___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

,___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org__
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0136: Message Archiving moved to Deprecated

2017-11-15 Thread Kozlov Konstantin

Too bad...XEP-0313 is still experimental and XEP-0136 is deprecated already.16.11.2017, 00:25, "Sam Whited" :Hi all,This email is to let you know that XEP-0136: Message Archiving [1] hasbeen moved to a stats of Deprecated per a vote of the Council. The newversion will be published and live on the website soon.—Sam[1]: https://xmpp.org/extensions/xep-0136.html___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

2017-11-15 Thread Kozlov Konstantin

That's nice!This XEP is still too raw.15.11.2017, 19:58, "Sam Whited" :Given the feedback on this thread, the council voted today NOT toadvance XEP-0313 to draft.The XEP will return to experimental until some of the feedback isaddressed.—SamOn Mon, Oct 16, 2017, at 12:38, Jonas Wielicki wrote: This message constitutes notice of a Last Call for comments on XEP-0313. Abstract: This document defines a protocol to query and control an archive of messages stored on a server. This Last Call begins today and shall end at the close of business on 2017-10-30. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___-- Sam Whiteds...@samwhited.com___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org__
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Styling

2017-11-15 Thread Kozlov Konstantin

Sounds reassuring. I guess I'll try to join the Council next time.15.11.2017, 10:49, "Jonas Wielicki" :On Mittwoch, 15. November 2017 10:32:29 CET Evgeny Khramtsov wrote: 1) no matter what arguments you bring if a Council member wants it, it will be merged making all XSF discussions pointlessThat is in fact incorrect. The whole council needs to be convinced, since voting is veto-based. A single "-1" counters a proposal.(This doesn’t touch your point on trend-making apps and de-facto standards though.),___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org__
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Styling

2017-11-14 Thread Kozlov Konstantin

  06.11.2017, 22:19, "Emmanuel Gil Peyrot" :On Mon, Nov 06, 2017 at 11:58:15AM -0600, Sam Whited wrote:People have been telling you countless times on standards@ thatembedding raw markup in the body is an extremely bad idea, with manyexamples.Markdown(-like) is NOT a plain text format, having the receiving clientchoose between rendering all formatting characters or stripping them isstupid, and requiring humans to mentally strip them out in olderclients is stupid; have you not seen the mess that OTR is for example?There is exactly no extensibility in this proposal, if tomorrow thetrend changes you will end up with all users of clients implementing itnot understanding what’s going on.Formatting really should be in a separate payload, so that clientswhich don’t understand it can use the plain text version and safelyignore the formatted one.And again, this XEP does not address any of the issues with XHTML-IM,web people will just pipe this through the first Markdown library andget rendering wrong, get more elements than listed here, and get a nicepassthrough of escaped HTML.   URL: https://xmpp.org/extensions/inbox/styling.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.Sorry for the rant, --Emmanuel Gil PeyroAbsolutely agree with each statement.The whole idea sounds awful. I hope the Council will never accept such inconsistent thing as an official XEP. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0167: Minor typo

2016-06-19 Thread Kozlov Konstantin

Hello, Florian!

19.06.2016, 11:33, "Florian Schmaus" :
> Thanks for your feedback. I've created a patch for this and issued a PR
> on github: https://github.com/xsf/xeps/pull/200
>
> Feel free to use this way in the future too. :)
Thanx, I will.

With my best regards,
 Konstantin
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0167: How to?

2016-06-19 Thread Kozlov Konstantin

Hello!

Just trying to implement XEP-0167: Jingle RTP Sessions in my client software. 
There's something, I can't understand.
According to 5. Negotiating a Jingle RTP Session, instances should start 
exchange media just after session-accept sent and acknowledged and connectivity 
established. To play RTP media stream, receiving party needs SDP, which could 
be build, using  element attributes. But session-accept stanza 
may have  element, which contains more than one  
element. And it says, that any of them could be used. How receiving party can 
determine, which payload type uses sending party, to generate SDP to play media 
stream?

With my best regards,
   Konstantin
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0167: Minor typo

2016-06-19 Thread Kozlov Konstantin

Hello!

I found a minor typo in XEP-0167: Jingle RTP Sessions, section 5, example 2 
comments. Last paragraph says:

In the following example, we imagine that the responder supports Speex at a 
clockrate of 8000 but not 16000, G729, and PCMA but not PMCU. Therefore the 
responder returns only two payload types (since PMCA was not offered).

Notice "PMCA" instead of "PCMA" at the end.

With my best regard,
Konstantin
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0301 (In-Band Real Time Text)

2013-05-29 Thread Kozlov Konstantin

 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
 clarify an existing protocol?
Yes
 2. Does the specification solve the problem stated in the introduction and 
 requirements?
Yes
 3. Do you plan to implement this specification in your code? If not, why not?
Yes
 4. Do you have any security concerns related to this specification?
No
 5. Is the specification accurate and clearly written?
Yes

Re: [Standards] disco identity for client/smartphone?

2012-12-03 Thread Kozlov Konstantin

03.12.2012, 12:30, Kevin Smith ke...@kismith.co.uk:
 On Fri, Nov 30, 2012 at 2:11 PM, Kozlov Konstantin yag...@yandex.ru wrote:

  30.11.2012, 12:26, Kevin Smith ke...@kismith.co.uk:
  On Thu, Nov 29, 2012 at 11:39 PM, Peter Saint-Andre stpe...@stpeter.im 
 wrote:
   Looking at http://xmpp.org/registrar/disco-categories.html I notice
   that we have disco identities for client/handheld (e.g., PDA) and
   client/phone (e.g., mobile phone), but I think those are a bit
   old-fashioned by now. We might want to add an identity for
   client/smartphone (i.e., a phone that can do a lot more than the
   old-style phones we had in mind when we defined client/phone).
  If this thing is capable of running an XMPP client on it, it's a 
 smartphone.
  Why?! Any cheap J2ME-enabled phone can run XMPP client without any problem.
  Usually we call smartphones only mobile devices with operating system 
 (Symbian, Windows CE/Mobile/Phone, iOS or Android).
  So, if you call any Java-enabled mobile phone smartphone, you should 
 agree that no mobile phones produced today at all. Only smartphones!

 Yes, that's the point - today's feature phones can do more than
 yesterday's smart phones, so this distinction doesn't provide any
 value that I can see. Distinguishing available features of clients is
 provided through 115/30.
Because of java overheads, it's almost impossible to write audio/video codec 
for J2ME. Writing codecs for device native OS is not a problem for last few 
years. So, most likely there will be no Jingle RTP support for a phone client, 
and there will be one for a smartphone client.

Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final

Hello!

28.09.2012, 16:23, Sergey Dobrov bin...@jrudevels.org:
 On 09/28/2012 06:35 AM, Peter Saint-Andre wrote:

  Another bigger problem is smilies. It's not obvious when the
  client should render smilies and when not. I'd prefer to forbid any
  text-based smilies in the XHTML-IM content
  Some of us actually prefer textual emoticons. :)

 Actually, me too :) But them have some problems to parse here, it adds
 some extra img tags actually in the mark up. :) So I'd prefer client
 to replace textual smilies BEFORE send them to the network. Obviously,
 the plain text representation of a message will be unchanged.

  Feel free to look at the old XEP-0038 for further considerations.
  but such way we really need a standardized way to attach images to
  a body.
  IMHO that would be XEP-0231.

 Yes, it seems to be pretty good here but it will be impossible to read
 images when your competitor is offline that can be nasty. But I don't
 know how to solve the problem anyway.

The only solution I see is adding special considerations for smilies. The 
smilies should be converted to some special type of images to allow client on 
the other side translate it.
I can suggest two possible syntaxes:
1. img / element without src attribute at all, which alt attribute 
contains textual representation of the smilie, so translator either translate 
it and display smilie image, or display alternative text if it cannot translate 
(or do not want to translate it at all, eg. smilie tranlation is diabled).
2. img / element with src attribute, containing URL with special scheme 
(eg. smilie:), whith path, containing properly escaped textual representation 
of the smilie.

With my best regards,
  Konstantin

Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final

Hello, Sergey

08.10.2012, 20:40, Sergey Dobrov bin...@jrudevels.org:
 Sorry for the double, please consider this message as wrong.

 On 10/08/2012 11:36 PM, Sergey Dobrov wrote:

  The only solution I see is adding special considerations for smilies. The 
 smilies should be converted to some special type of images to allow client 
 on the other side translate it.
  I can suggest two possible syntaxes:
  1. img / element without src attribute at all, which alt attribute 
 contains textual representation of the smilie, so translator either 
 translate it and display smilie image, or display alternative text if it 
 cannot translate (or do not want to translate it at all, eg. smilie 
 tranlation is diabled).
  Unfortunately, we have to be compatible with XHTML, I think :)
Well, I don't see any incompatibility with XHTML here.

  2. img / element with src attribute, containing URL with special 
 scheme (eg. smilie:), whith path, containing properly escaped textual 
 representation of the smilie.
  Don't know how complex a process of inventing a new URI schema but I
  think that actually transmission of smilies as images is okay too but it
  needs to be thought over and over again :)
Yeah, let's think about it.

 With best regards,
 Sergey Dobrov,
 XMPP Developer and JRuDevels.org founder.

With my best regards,
 Konstantin

Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final

Hello!

  2. img / element with src attribute, containing URL with special scheme 
 (eg. smilie:), whith path, containing properly escaped textual 
 representation of the smilie.

 Don't know how complicated a process of inventing a new URI schema is.
 But I actually think that we can use real images with alternate text
 which contains text smile representation.
Well... this way just breaks the main advantage of text-based smilies: low 
traffic. Why do we need smilies at all, if we can just send embedded images 
anyway?

With my best regards,
   Konstantin

Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final