Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/12 5:41 AM, Kevin Smith wrote: On Mon, Oct 15, 2012 at 3:33 PM, Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/12 12:21 AM, Andreas Kuckartz wrote: I agree with that sentiment. Green-colored text and strange fonts were popular when MySpace was popular. This is something from the past, not the present or future. The present and future require semantic elements (such as blockquote/) and attributes (such as those used by RDFa). I think that's right. So how about the following change... OLD The use of structural elements is NOT RECOMMENDED where presentational styles are desired, which is why very few structural elements are specified herein. Implementations SHOULD use appropriate 'style' attributes (e.g., span style='font-weight: bold'this is bold/span and p style='margin-left: 5%'this is indented/p) rather than XHTML structural elements (e.g., strong/ and blockquote/) wherever possible. NEW Where strictly presentational style are desired (e.g., colored text), it might be necessary to use use 'style' attributes (e.g., span style='font-color: green'this is green/span). However, where possible it is instead RECOMMENDED to use appropriate structural elements (e.g., strong/ and blockquote/ instead of, say, style='font-weight: bold' or style='margin-left: 5%'). As long as we're not changing the subset of tags allowed, this seems sensible to me. Right, no changes to the subset of tags. I'll publish a new version and the Council can decide how it would like to proceed. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlC2DVAACgkQNL8k5A2w/vzjJQCfazLLMzfqzVP4w+VdfbHIwp49 LpYAni4ll1Va3kXWO+4UXoz5m9TZmwct =H5KZ -END PGP SIGNATURE-
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
On Mon, Oct 15, 2012 at 3:33 PM, Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/12 12:21 AM, Andreas Kuckartz wrote: I agree with that sentiment. Green-colored text and strange fonts were popular when MySpace was popular. This is something from the past, not the present or future. The present and future require semantic elements (such as blockquote/) and attributes (such as those used by RDFa). I think that's right. So how about the following change... OLD The use of structural elements is NOT RECOMMENDED where presentational styles are desired, which is why very few structural elements are specified herein. Implementations SHOULD use appropriate 'style' attributes (e.g., span style='font-weight: bold'this is bold/span and p style='margin-left: 5%'this is indented/p) rather than XHTML structural elements (e.g., strong/ and blockquote/) wherever possible. NEW Where strictly presentational style are desired (e.g., colored text), it might be necessary to use use 'style' attributes (e.g., span style='font-color: green'this is green/span). However, where possible it is instead RECOMMENDED to use appropriate structural elements (e.g., strong/ and blockquote/ instead of, say, style='font-weight: bold' or style='margin-left: 5%'). As long as we're not changing the subset of tags allowed, this seems sensible to me. /K
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
I agree with that sentiment. Green-colored text and strange fonts were popular when MySpace was popular. This is something from the past, not the present or future. The present and future require semantic elements (such as blockquote/) and attributes (such as those used by RDFa). Cheers, Andreas Peter Saint-Andre: On 9/27/12 5:32 PM, Peter Saint-Andre wrote: On 7/31/12 6:43 PM, Mathieu Pasquet wrote: I am also not sure about the strong/ and blockquote/ elements: they are shown as a recommended element to support (7.8), but the business rules (8.7) states that they should not be used, but rather span/ or p/ with appropriate style attributes. Is it only for backward compatibility, then? I think we need a broader discussion of this topic, since it caused so much controversy when we first defined XHTML-IM. I will review the old list discussion and more modern opinions on this topic, then post to the list again. Here is the relevant business rule: ### The use of structural elements is NOT RECOMMENDED where presentational styles are desired, which is why very few structural elements are specified herein. Implementations SHOULD use appropriate 'style' attributes (e.g., span style='font-weight: bold'this is bold/span and p style='margin-left: 5%'this is indented/p) rather than XHTML structural elements (e.g., strong/ and blockquote/) wherever possible. ### That now seems wrongheaded to me. Sure, *if* you just want a pretty presentation (say, a bit of green-colored text), then 'style' attributes are appropriate. However, it seems to me that if you want to quote something or emphasize something then using blockquote/ or em/ is the right thing to do. (I also wonder why we don't support q/ for inline quotation...) Peter
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/12 12:21 AM, Andreas Kuckartz wrote: I agree with that sentiment. Green-colored text and strange fonts were popular when MySpace was popular. This is something from the past, not the present or future. The present and future require semantic elements (such as blockquote/) and attributes (such as those used by RDFa). I think that's right. So how about the following change... OLD The use of structural elements is NOT RECOMMENDED where presentational styles are desired, which is why very few structural elements are specified herein. Implementations SHOULD use appropriate 'style' attributes (e.g., span style='font-weight: bold'this is bold/span and p style='margin-left: 5%'this is indented/p) rather than XHTML structural elements (e.g., strong/ and blockquote/) wherever possible. NEW Where strictly presentational style are desired (e.g., colored text), it might be necessary to use use 'style' attributes (e.g., span style='font-color: green'this is green/span). However, where possible it is instead RECOMMENDED to use appropriate structural elements (e.g., strong/ and blockquote/ instead of, say, style='font-weight: bold' or style='margin-left: 5%'). Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB8Hs4ACgkQNL8k5A2w/vxiMwCfSUAJJEpXaNLLgH1jH460VBKS SsoAoO6pG90B7HzgCWJAtXBmsXi18kXx =Utuf -END PGP SIGNATURE-
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/12/12 7:53 AM, Peter Saint-Andre wrote: On 10/12/12 4:07 AM, Sergey Dobrov wrote: On 10/11/2012 10:23 PM, Peter Saint-Andre wrote: On 9/27/12 5:32 PM, Peter Saint-Andre wrote: (I also wonder why we don't support q/ for inline quotation...) Yes, it seems that the set of allowed tags should be reviewed too. Maybe. :) I'm sure we had good reasons for the limited subset we defined in 2003-2004, and I am not sure we want to reconsider every element and attribute when the XEP is so mature. I really don't want to re-open a discussion about each and every XHTML element, so I'm sorry about the comment on q/ for inline quotation. In any case, what's in XEP-0071 is a recommended profile, so developers are free to support more structural elements if desired. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB8H5YACgkQNL8k5A2w/vzkXQCeNVe3gocxbZGwqJfLk1QQD3xs tFEAnAsA8kvnE01ot4Rh/tRoqXig1ZIm =BJLf -END PGP SIGNATURE-
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
On 10/11/2012 10:23 PM, Peter Saint-Andre wrote: On 9/27/12 5:32 PM, Peter Saint-Andre wrote: On 7/31/12 6:43 PM, Mathieu Pasquet wrote: I am also not sure about the strong/ and blockquote/ elements: they are shown as a recommended element to support (7.8), but the business rules (8.7) states that they should not be used, but rather span/ or p/ with appropriate style attributes. Is it only for backward compatibility, then? I think we need a broader discussion of this topic, since it caused so much controversy when we first defined XHTML-IM. I will review the old list discussion and more modern opinions on this topic, then post to the list again. Here is the relevant business rule: ### The use of structural elements is NOT RECOMMENDED where presentational styles are desired, which is why very few structural elements are specified herein. Implementations SHOULD use appropriate 'style' attributes (e.g., span style='font-weight: bold'this is bold/span and p style='margin-left: 5%'this is indented/p) rather than XHTML structural elements (e.g., strong/ and blockquote/) wherever possible. ### That now seems wrongheaded to me. Sure, *if* you just want a pretty presentation (say, a bit of green-colored text), then 'style' attributes are appropriate. However, it seems to me that if you want to quote something or emphasize something then using blockquote/ or em/ is the right thing to do. agree. It would be a nasty thing to make it impossible to grant rights to the sender to control the styles for the recipient. (I also wonder why we don't support q/ for inline quotation...) Yes, it seems that the set of allowed tags should be reviewed too. Peter -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
On 10/12/12 4:07 AM, Sergey Dobrov wrote: On 10/11/2012 10:23 PM, Peter Saint-Andre wrote: On 9/27/12 5:32 PM, Peter Saint-Andre wrote: On 7/31/12 6:43 PM, Mathieu Pasquet wrote: I am also not sure about the strong/ and blockquote/ elements: they are shown as a recommended element to support (7.8), but the business rules (8.7) states that they should not be used, but rather span/ or p/ with appropriate style attributes. Is it only for backward compatibility, then? I think we need a broader discussion of this topic, since it caused so much controversy when we first defined XHTML-IM. I will review the old list discussion and more modern opinions on this topic, then post to the list again. Here is the relevant business rule: ### The use of structural elements is NOT RECOMMENDED where presentational styles are desired, which is why very few structural elements are specified herein. Implementations SHOULD use appropriate 'style' attributes (e.g., span style='font-weight: bold'this is bold/span and p style='margin-left: 5%'this is indented/p) rather than XHTML structural elements (e.g., strong/ and blockquote/) wherever possible. ### That now seems wrongheaded to me. Sure, *if* you just want a pretty presentation (say, a bit of green-colored text), then 'style' attributes are appropriate. However, it seems to me that if you want to quote something or emphasize something then using blockquote/ or em/ is the right thing to do. agree. It would be a nasty thing to make it impossible to grant rights to the sender to control the styles for the recipient. (I also wonder why we don't support q/ for inline quotation...) Yes, it seems that the set of allowed tags should be reviewed too. Maybe. :) I'm sure we had good reasons for the limited subset we defined in 2003-2004, and I am not sure we want to reconsider every element and attribute when the XEP is so mature. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/27/12 5:32 PM, Peter Saint-Andre wrote: On 7/31/12 6:43 PM, Mathieu Pasquet wrote: I am also not sure about the strong/ and blockquote/ elements: they are shown as a recommended element to support (7.8), but the business rules (8.7) states that they should not be used, but rather span/ or p/ with appropriate style attributes. Is it only for backward compatibility, then? I think we need a broader discussion of this topic, since it caused so much controversy when we first defined XHTML-IM. I will review the old list discussion and more modern opinions on this topic, then post to the list again. Here is the relevant business rule: ### The use of structural elements is NOT RECOMMENDED where presentational styles are desired, which is why very few structural elements are specified herein. Implementations SHOULD use appropriate 'style' attributes (e.g., span style='font-weight: bold'this is bold/span and p style='margin-left: 5%'this is indented/p) rather than XHTML structural elements (e.g., strong/ and blockquote/) wherever possible. ### That now seems wrongheaded to me. Sure, *if* you just want a pretty presentation (say, a bit of green-colored text), then 'style' attributes are appropriate. However, it seems to me that if you want to quote something or emphasize something then using blockquote/ or em/ is the right thing to do. (I also wonder why we don't support q/ for inline quotation...) Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB25IIACgkQNL8k5A2w/vx/4QCfeOT5n8Hq9vF4vYBQEvpcLADQ pvIAnAuoUaJdM0IxYcFWaGDQn9cJ/h6r =pV+0 -END PGP SIGNATURE-
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
On 10/01/2012 11:18 PM, Kozlov Konstantin wrote: Hello! Hello Konstantin, 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). Unfortunately, we have to be compatible with XHTML, I think :) 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 :) With my best regards, Konstantin -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
On 10/01/2012 11:18 PM, Kozlov Konstantin wrote: Hello! Hello Konstantin, 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). Unfortunately, we have to stay compatible with XHTML, I think :) 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. With my best regards, Thanks for your feedback! Konstantin -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
Sorry for the double, please consider this message as wrong. On 10/08/2012 11:36 PM, Sergey Dobrov wrote: On 10/01/2012 11:18 PM, Kozlov Konstantin wrote: Hello! Hello Konstantin, 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). Unfortunately, we have to be compatible with XHTML, I think :) 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 :) With my best regards, Konstantin -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
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
On 10/09/2012 12:04 AM, Kozlov Konstantin wrote: Hello! 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. src attribute is required for img tag in XHTML: xs:element name=img xs:complexType xs:attributeGroup ref=attrs/ xs:attribute name=src use=required type=URI/ ... 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? Actually, I don't think that it's required to say about lightweight when talking about XHTML-IM ;) These clients that don't want to retrieve much data from the network can just hide xhtml-im from their disco-features. With my best regards, Konstantin -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
Hello, Sergey! 09.10.2012, 00:59, Sergey Dobrov bin...@jrudevels.org: On 10/09/2012 12:04 AM, Kozlov Konstantin wrote: Well, I don't see any incompatibility with XHTML here. src attribute is required for img tag in XHTML: xs:element name=img xs:complexType xs:attributeGroup ref=attrs/ xs:attribute name=src use=required type=URI/ Ok, IC. 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? Actually, I don't think that it's required to say about lightweight when talking about XHTML-IM ;) These clients that don't want to retrieve much data from the network can just hide xhtml-im from their disco-features. To tell the truth, XHTML-IM doesn't mean high traffic consumption at all. Bot XML and HTML code are compressed even better than plain text because of a lot of repeating elements. Unlike Base64-encoded data, which is almost incompressible. With my best regards, Konstantin
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
On 09/28/2012 06:35 AM, Peter Saint-Andre wrote: On 9/27/12 9:49 AM, Sergey Dobrov wrote: On 09/27/2012 09:38 PM, Peter Saint-Andre wrote: On 8/22/12 2:13 PM, Kevin Smith wrote: On Wed, Aug 22, 2012 at 8:56 PM, Joe Hildebrand (jhildebr) jhild...@cisco.com wrote: On 8/22/12 10:33 AM, Matthew Miller linuxw...@outer-planes.net wrote: I agree with Sergey. If you received XHTML-IM, then any other rich text transform ought to be disabled/bypassed. What about URLs that are not in a/ elements? I remember us changing the XEP years ago to explicitly call this out. Links should be linkified at the sender end, not by the recipient, for XHTML-IM. Yes, business rule #10 in XEP-0071 says: When rendering XHTML-IM content, a user agent SHOULD NOT render as a hyperlink text that is not structured via the a/ element from the Hypertext Module; therefore if the sender wishes text to be linked, the sending user agent MUST represent the text using the a/ element and appropriate attributes. However, that applies only to anchors. Do we need to broaden the rule to cover all HTML elements? If so, I suggest: When rendering XHTML-IM content, a receiving user agent MUST NOT render as XHTML any text that was not structured by the sending user agent using XHTML elements and attributes; if the sender wishes text to be structured (e.g., for certain words to be emphasized or for URIs to be linked), the sending user agent MUST represent the text using the appropriate XHTML elements and attributes. 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. Peter -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder. -- Sent from my Gentoo GNU/Linux PC. With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder. xmpp:bin...@jrudevels.org
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
On 09/27/2012 09:45 PM, Peter Saint-Andre wrote: On 8/1/12 3:32 AM, Sergey Dobrov wrote: Sergey, thanks for the feedback. Surely, You are always welcome, I am back from my vacation and can continue my work :) Thank you too for your work. 3. Is the text of XEP-0071 clear and unambiguous? Are more examples needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. Why don't we have a possibility to use the del HTML tag? Could you please describe why you think the del tab would be useful? For instance, do you think we would use that in the message correction spec, or (for microblogging) in the equivalent of modified tweets? I didn't think about it actually :) I needed it when I was developing one of XEP-277 transports, the markup of the legacy system supports the [s] bb code, so I need it too. But deeper my point is that as far as we support xhtml:strong, em, and so on, we should support del/ins too just to be consistent: I can outline some text with strong or em and the client will be able to style the text according to user preferences but here the only option is to use CSS style hardcoded. Sorry, if my statement is not clear :) Peter -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder. -- Sent from my Gentoo GNU/Linux PC. With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder. xmpp:bin...@jrudevels.org
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/22/12 2:13 PM, Kevin Smith wrote: On Wed, Aug 22, 2012 at 8:56 PM, Joe Hildebrand (jhildebr) jhild...@cisco.com wrote: On 8/22/12 10:33 AM, Matthew Miller linuxw...@outer-planes.net wrote: I agree with Sergey. If you received XHTML-IM, then any other rich text transform ought to be disabled/bypassed. What about URLs that are not in a/ elements? I remember us changing the XEP years ago to explicitly call this out. Links should be linkified at the sender end, not by the recipient, for XHTML-IM. Yes, business rule #10 in XEP-0071 says: When rendering XHTML-IM content, a user agent SHOULD NOT render as a hyperlink text that is not structured via the a/ element from the Hypertext Module; therefore if the sender wishes text to be linked, the sending user agent MUST represent the text using the a/ element and appropriate attributes. However, that applies only to anchors. Do we need to broaden the rule to cover all HTML elements? If so, I suggest: When rendering XHTML-IM content, a receiving user agent MUST NOT render as XHTML any text that was not structured by the sending user agent using XHTML elements and attributes; if the sender wishes text to be structured (e.g., for certain words to be emphasized or for URIs to be linked), the sending user agent MUST represent the text using the appropriate XHTML elements and attributes. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBkZNYACgkQNL8k5A2w/vzR7wCgyt7GtamQsdm4ITF/r+3vw08W BzIAoOB+VwYzXbQmhGzTY+xzKskbsc5k =i0gM -END PGP SIGNATURE-
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/1/12 3:32 AM, Sergey Dobrov wrote: Sergey, thanks for the feedback. 3. Is the text of XEP-0071 clear and unambiguous? Are more examples needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. Why don't we have a possibility to use the del HTML tag? Could you please describe why you think the del tab would be useful? For instance, do you think we would use that in the message correction spec, or (for microblogging) in the equivalent of modified tweets? Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBkZqYACgkQNL8k5A2w/vzofACg/RD29ODFfPlHAjPhOY8KZH12 4y8AoIxKguJMmkyDb6OcjWx12Aj8DElk =vDhM -END PGP SIGNATURE-
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/1/12 3:42 AM, Sergey Dobrov wrote: Hello. On 08/01/2012 07:43 AM, Mathieu Pasquet wrote: I am also not sure about the strong/ and blockquote/ elements: they are shown as a recommended element to support (7.8), but the business rules (8.7) states that they should not be used, but rather span/ or p/ with appropriate style attributes. Is it only for backward compatibility, then? I'm using the blockquote element very intensive. I don't think that we should give a preference to style attributes because IM differs from web and we need messages to be more semantic than to be more styled. I.e. we need to support the same style for all messages as strong as it possible to prevent transformation of a chat window to an Xmas tree, so we need to outline semantic groups rather than style them to provide a possibility to theme them by recipient preference. Also, it's easier to parse such message by machines to provide some advance search possibilities and etc. So I don't imagine the XHTML-IM without such things as blockquote, cite, code, strong, em, etc. As you can imagine, we had some debates about this when we initially worked on XHTML-IM back in 2003-2004. Some people were in favor of a semantic approach, others in favor of a stylistic approach (these debates mirrored somewhat the similar debates in the W3C and the web community in general). I tend to agree now that the semantic approach makes more sense for use in IM, and you have explained the reasoning quite well. There is the matter of the img/ tag that accepts a data:base64 as a src, leading to very big stanzas. I think that maybe the XEP could state that whenever possible, the use of base64 data should be avoided, at least in MUCs, where the message is replicated as many times as there are users, leading to high bandwith usage (although if I remember correctly, most servers set the max stanza size to 10 KiB). Usually something between 10k and 64k. But yes, there are restrictions, and I tend to agree that we should strongly prefer pointers to external images over inline data: URLs. agree. possibly, we need to prefer XEP-231 for that? Probably. I'll look at the XEP in more detail and propose some text on this list. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBkaB8ACgkQNL8k5A2w/vzmCQCdGvwlx+vf7w/ORwLjGJTCayRy 5j8AnA6XYZshvzdZ1JL2WcZoRKqtrEsq =fhID -END PGP SIGNATURE-
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
On 09/27/2012 09:38 PM, Peter Saint-Andre wrote: On 8/22/12 2:13 PM, Kevin Smith wrote: On Wed, Aug 22, 2012 at 8:56 PM, Joe Hildebrand (jhildebr) jhild...@cisco.com wrote: On 8/22/12 10:33 AM, Matthew Miller linuxw...@outer-planes.net wrote: I agree with Sergey. If you received XHTML-IM, then any other rich text transform ought to be disabled/bypassed. What about URLs that are not in a/ elements? I remember us changing the XEP years ago to explicitly call this out. Links should be linkified at the sender end, not by the recipient, for XHTML-IM. Yes, business rule #10 in XEP-0071 says: When rendering XHTML-IM content, a user agent SHOULD NOT render as a hyperlink text that is not structured via the a/ element from the Hypertext Module; therefore if the sender wishes text to be linked, the sending user agent MUST represent the text using the a/ element and appropriate attributes. However, that applies only to anchors. Do we need to broaden the rule to cover all HTML elements? If so, I suggest: When rendering XHTML-IM content, a receiving user agent MUST NOT render as XHTML any text that was not structured by the sending user agent using XHTML elements and attributes; if the sender wishes text to be structured (e.g., for certain words to be emphasized or for URIs to be linked), the sending user agent MUST represent the text using the appropriate XHTML elements and attributes. 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 but such way we really need a standardized way to attach images to a body. Peter -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder. -- Sent from my Gentoo GNU/Linux PC. With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder. xmpp:bin...@jrudevels.org
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/27/12 8:52 AM, Peter Saint-Andre wrote: On 8/1/12 3:42 AM, Sergey Dobrov wrote: On 08/01/2012 07:43 AM, Mathieu Pasquet wrote: There is the matter of the img/ tag that accepts a data:base64 as a src, leading to very big stanzas. I think that maybe the XEP could state that whenever possible, the use of base64 data should be avoided, at least in MUCs, where the message is replicated as many times as there are users, leading to high bandwith usage (although if I remember correctly, most servers set the max stanza size to 10 KiB). Usually something between 10k and 64k. But yes, there are restrictions, and I tend to agree that we should strongly prefer pointers to external images over inline data: URLs. agree. possibly, we need to prefer XEP-231 for that? Probably. I'll look at the XEP in more detail and propose some text on this list. Here is proposed text for Section 7.5... ### The XHTML specification allows a data: URL RFC 2397 [22] as the value of the 'src' attribute. This is NOT RECOMMENDED for use in XHTML-IM, because it can significantly increase the size of the message stanza and XMPP is not optimized for large stanzas. If the image data is small (less than 8 kilobytes), clients MAY use Bits of Binary [23] in coordination with XHTML-IM; if the image data is large, the value of the 'src' SHOULD be a pointer to an externally available file for the image (or the sender SHOULD use a dedicated file transfer method such as In-Band Bytestreams [24] or SOCKS5 Bytestreams [25]). ### Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBk3+4ACgkQNL8k5A2w/vy3HgCgg1k3S9pvaZhyG/pji+cx1Uvn OXcAnR4wrlTKotpvcN4jk1tCzBbwFt1k =X2kD -END PGP SIGNATURE-
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for your feedback. Comments inline. On 7/31/12 6:43 PM, Mathieu Pasquet wrote: Is the text of XEP-0071 clear and unambiguous? Are more examples needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. 7.6 states that the style attribute MUST be supported, but 7.6.1 on the other hand shows a list of RECOMMENDED CSS1 properties. If a client does not implement any of those properties, isn’t it the same as dropping the style attribute (and therefore not supporting it)? Yes. The intent of specifying various RECOMMENDED properties in 7.6.1 is to discourage clients from supporting even more style properties than those listed (note that there is no official way in XHTML modularization to limit the scope of style properties). I am also not sure about the strong/ and blockquote/ elements: they are shown as a recommended element to support (7.8), but the business rules (8.7) states that they should not be used, but rather span/ or p/ with appropriate style attributes. Is it only for backward compatibility, then? I think we need a broader discussion of this topic, since it caused so much controversy when we first defined XHTML-IM. I will review the old list discussion and more modern opinions on this topic, then post to the list again. There is the matter of the img/ tag that accepts a data:base64 as a src, leading to very big stanzas. I think that maybe the XEP could state that whenever possible, the use of base64 data should be avoided, at least in MUCs, where the message is replicated as many times as there are users, leading to high bandwith usage (although if I remember correctly, most servers set the max stanza size to 10 KiB). See other messages in this thread. Finally, although we have a somehow working partial implementation of XEP-0071 in Poezio, I wouldn’t count it as a proper codebase for XEP validation, because the limitations of console clients do not allow a full implementation (e.g. font changes, text-decorations other than underline, relative margins, etc). Yes, that makes sense. Thanks for implementing as much as possible given the form-factor of the console. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBk4f8ACgkQNL8k5A2w/vzjqwCg7tzJ1L6uj6rvezJLN5pQ7KQC HAMAnA806q+IrnA4bcNVHdvWYnSVxGm1 =e1QZ -END PGP SIGNATURE-
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/27/12 9:49 AM, Sergey Dobrov wrote: On 09/27/2012 09:38 PM, Peter Saint-Andre wrote: On 8/22/12 2:13 PM, Kevin Smith wrote: On Wed, Aug 22, 2012 at 8:56 PM, Joe Hildebrand (jhildebr) jhild...@cisco.com wrote: On 8/22/12 10:33 AM, Matthew Miller linuxw...@outer-planes.net wrote: I agree with Sergey. If you received XHTML-IM, then any other rich text transform ought to be disabled/bypassed. What about URLs that are not in a/ elements? I remember us changing the XEP years ago to explicitly call this out. Links should be linkified at the sender end, not by the recipient, for XHTML-IM. Yes, business rule #10 in XEP-0071 says: When rendering XHTML-IM content, a user agent SHOULD NOT render as a hyperlink text that is not structured via the a/ element from the Hypertext Module; therefore if the sender wishes text to be linked, the sending user agent MUST represent the text using the a/ element and appropriate attributes. However, that applies only to anchors. Do we need to broaden the rule to cover all HTML elements? If so, I suggest: When rendering XHTML-IM content, a receiving user agent MUST NOT render as XHTML any text that was not structured by the sending user agent using XHTML elements and attributes; if the sender wishes text to be structured (e.g., for certain words to be emphasized or for URIs to be linked), the sending user agent MUST represent the text using the appropriate XHTML elements and attributes. 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. :) 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. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBk4twACgkQNL8k5A2w/vycVQCePQZPP4Gp2mQC8XL2mahMTzHs YqMAn2IPtioxDRv2ah2I5kP0V3AsBNnQ =NYos -END PGP SIGNATURE-
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
On 08/22/2012 02:31 AM, Joe Hildebrand (jhildebr) wrote: Or suggest to change *this* to strongthis/strong or strong*this*/strong. No, the thing is that a client changes this: *this*strongthat/strong in the *incoming* message to this: strongthis/strongstrongthat/strong which is obviously wrong since a sender can make things strong without such plain text formatting :) On 8/21/12 2:57 AM, Sergey Dobrov bin...@jrudevels.org wrote: Btw, often implementation of XHTML-IM conflicts with internal hyperlinks/smiles/plain text formatting like *this*. Maybe it will be useful to add recommendation to switch any these parsers off when a client have a deal with XHTML-IM message? On 08/01/2012 03:58 AM, Peter Saint-Andre wrote: At its meeting on July 25, 2012, the XMPP Council agreed to issue a Call for Experience regarding XEP-0071 (XHTML-IM), in preparation for perhaps advancing this specification from Draft to Final in the XSF's standards process. To help the Council decide whether this XEP is ready to advance to a status of Final, the Council would like to gather the following information: 1. What software has implemented XEP-0071? Please note that the protocol must be implemented in at least two separate codebases (and preferably more) in order to advance from Draft to Final. 2. Have developers experienced any problems with the protocol as defined in XEP-0071? If so, please describe the problems and, if possible, suggested solutions. 3. Is the text of XEP-0071 clear and unambiguous? Are more examples needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. If you have any comments about advancing XEP-0071 from Draft to Final, please provide them by the close of business on Friday, August 31, 2012. After the Call for Experience, this XEP might undergo revisions to address feedback received, after which it will be presented to the XMPP Council for voting to a status of Final. You can review the specification here: http://www.xmpp.org/extensions/xep-0071.html Please send all feedback to the standards@xmpp.org discussion list. Thanks! Peter -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I agree with Sergey. If you received XHTML-IM, then any other rich text transform ought to be disabled/bypassed. - - mm Matthew A. Miller http://goo.gl/LK55L On Aug 22, 2012, at 02:35, Sergey Dobrov wrote: On 08/22/2012 02:31 AM, Joe Hildebrand (jhildebr) wrote: Or suggest to change *this* to strongthis/strong or strong*this*/strong. No, the thing is that a client changes this: *this*strongthat/strong in the *incoming* message to this: strongthis/strongstrongthat/strong which is obviously wrong since a sender can make things strong without such plain text formatting :) On 8/21/12 2:57 AM, Sergey Dobrov bin...@jrudevels.org wrote: Btw, often implementation of XHTML-IM conflicts with internal hyperlinks/smiles/plain text formatting like *this*. Maybe it will be useful to add recommendation to switch any these parsers off when a client have a deal with XHTML-IM message? On 08/01/2012 03:58 AM, Peter Saint-Andre wrote: At its meeting on July 25, 2012, the XMPP Council agreed to issue a Call for Experience regarding XEP-0071 (XHTML-IM), in preparation for perhaps advancing this specification from Draft to Final in the XSF's standards process. To help the Council decide whether this XEP is ready to advance to a status of Final, the Council would like to gather the following information: 1. What software has implemented XEP-0071? Please note that the protocol must be implemented in at least two separate codebases (and preferably more) in order to advance from Draft to Final. 2. Have developers experienced any problems with the protocol as defined in XEP-0071? If so, please describe the problems and, if possible, suggested solutions. 3. Is the text of XEP-0071 clear and unambiguous? Are more examples needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. If you have any comments about advancing XEP-0071 from Draft to Final, please provide them by the close of business on Friday, August 31, 2012. After the Call for Experience, this XEP might undergo revisions to address feedback received, after which it will be presented to the XMPP Council for voting to a status of Final. You can review the specification here: http://www.xmpp.org/extensions/xep-0071.html Please send all feedback to the standards@xmpp.org discussion list. Thanks! Peter -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQNQngAAoJEJq6Ou0cgrSPBE8H/0p+Vd00IUsT8aXWqhcDH4sJ JXA+NntCufRkABSyKHdSpf8MBqWQySxIs09fBTPZZeB8YCecDnnWVxs6NX7fgGCQ 8e6GSR8iVO+5b76jkuoIZMxGbl3/vHmX6wuoujruCnsWmAXPfgcONZNXeaTpxMiD zMMHou+ctdJQUstA3eIBN50ckgwQOTPPqDtwSV8F3Z3rOKp6wO5fYrP2867nuLOI vhU5V1HrEVIMPfiesILgg+ckQuUrbQ6i2NcE+X+RckH9uilX3cPdXJlFOpaeaI2+ AHOEioszYLbD/yWSIOAaVLZ8USUVZbV8jAYmy6Cyu8qDfmCo9zjBTyIXFW+4kcI= =Cupk -END PGP SIGNATURE-
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
On 8/22/12 10:33 AM, Matthew Miller linuxw...@outer-planes.net wrote: I agree with Sergey. If you received XHTML-IM, then any other rich text transform ought to be disabled/bypassed. What about URLs that are not in a/ elements? -- Joe Hildebrand
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 22, 2012, at 13:56, Joe Hildebrand (jhildebr) wrote: On 8/22/12 10:33 AM, Matthew Miller linuxw...@outer-planes.net wrote: I agree with Sergey. If you received XHTML-IM, then any other rich text transform ought to be disabled/bypassed. What about URLs that are not in a/ elements? Frankly, too bad so sad. The sender really ought to have put them in anchors in the first place. - - mm Matthew A. Miller http://goo.gl/LK55L -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQNToBAAoJEJq6Ou0cgrSPtFYH/R6RHTgw8V0vfb7SfLk+5Lgr MZP7gbmxZapO7+JcW5blfTY96D7onAjQNQuOZy0kG5d3V2xZ7ORbFPlH+Axs55Ud MzCPyKUBgT/7tNddFxhhyN1Vr6rVk0Mwf5scHqVI2Q0jUUEj62+w3j89Lvo8wHn7 SnRI4KKpGJfrFcPlD0v6zo0IQLXS+zjzcaNamJaLp0R47CPhAlaHa+hR3ff5lo60 DQgRkEZU9bdtsiI0ZSrUXEAm+gZN7Z6MG8YaMvSbDLOUrycNbmTtiEA8H8ejxtie Yzp9c+MjjwlU2f5TutETqmiYDA+De/q0PEzp+W+nm9EA8BlzSUrGdvb1e3bhftk= =s7XP -END PGP SIGNATURE-
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
On Wed, Aug 22, 2012 at 3:58 PM, Matthew Miller linuxw...@outer-planes.net wrote: What about URLs that are not in a/ elements? Frankly, too bad so sad. The sender really ought to have put them in anchors in the first place. It seems some XHTML-IM clients seem to URL-ize links that are not already URL-ized. This goes for discussion forums phpBB always URL-ize links that are not in [url] [/url] There is a lot of precedent here on automated URL-ization on URL's that the originator did not bother to URL-ize. User complaints about non-clickable clicks will force XMPP authors to URL-ize links not in a Yes, ugly solution, but customer is often king. :-/
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
On Wed, Aug 22, 2012 at 8:56 PM, Joe Hildebrand (jhildebr) jhild...@cisco.com wrote: On 8/22/12 10:33 AM, Matthew Miller linuxw...@outer-planes.net wrote: I agree with Sergey. If you received XHTML-IM, then any other rich text transform ought to be disabled/bypassed. What about URLs that are not in a/ elements? I remember us changing the XEP years ago to explicitly call this out. Links should be linkified at the sender end, not by the recipient, for XHTML-IM. /K
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
On Wed, Aug 22, 2012 at 9:02 PM, Mark Rejhon marky...@gmail.com wrote: On Wed, Aug 22, 2012 at 3:58 PM, Matthew Miller linuxw...@outer-planes.net wrote: What about URLs that are not in a/ elements? Frankly, too bad so sad. The sender really ought to have put them in anchors in the first place. It seems some XHTML-IM clients seem to URL-ize links that are not already URL-ized. This goes for discussion forums phpBB always URL-ize links that are not in [url] [/url] phpBB is the sender, not the receiver of these data - it's not your web browser that's automatically linkifying. Senders can automatically linkify XHTML-IM, recipients shouldn't. /K
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
Or suggest to change *this* to strongthis/strong or strong*this*/strong. On 8/21/12 2:57 AM, Sergey Dobrov bin...@jrudevels.org wrote: Btw, often implementation of XHTML-IM conflicts with internal hyperlinks/smiles/plain text formatting like *this*. Maybe it will be useful to add recommendation to switch any these parsers off when a client have a deal with XHTML-IM message? On 08/01/2012 03:58 AM, Peter Saint-Andre wrote: At its meeting on July 25, 2012, the XMPP Council agreed to issue a Call for Experience regarding XEP-0071 (XHTML-IM), in preparation for perhaps advancing this specification from Draft to Final in the XSF's standards process. To help the Council decide whether this XEP is ready to advance to a status of Final, the Council would like to gather the following information: 1. What software has implemented XEP-0071? Please note that the protocol must be implemented in at least two separate codebases (and preferably more) in order to advance from Draft to Final. 2. Have developers experienced any problems with the protocol as defined in XEP-0071? If so, please describe the problems and, if possible, suggested solutions. 3. Is the text of XEP-0071 clear and unambiguous? Are more examples needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. If you have any comments about advancing XEP-0071 from Draft to Final, please provide them by the close of business on Friday, August 31, 2012. After the Call for Experience, this XEP might undergo revisions to address feedback received, after which it will be presented to the XMPP Council for voting to a status of Final. You can review the specification here: http://www.xmpp.org/extensions/xep-0071.html Please send all feedback to the standards@xmpp.org discussion list. Thanks! Peter -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder. -- Joe Hildebrand
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
On 08/01/2012 03:58 AM, Peter Saint-Andre wrote: At its meeting on July 25, 2012, the XMPP Council agreed to issue a Call for Experience regarding XEP-0071 (XHTML-IM), in preparation for perhaps advancing this specification from Draft to Final in the XSF's standards process. To help the Council decide whether this XEP is ready to advance to a status of Final, the Council would like to gather the following information: 1. What software has implemented XEP-0071? Please note that the protocol must be implemented in at least two separate codebases (and preferably more) in order to advance from Draft to Final. I know that the protocol is implemented in Gajim and Psi. Both of them have some little problems but both are ready to use, from my point of view. For example, Psi doesn't support img/ with external images links and doesn't support HTML-IM input, only rendering of incoming messages. Gajim has basic support of composing and good rendering quality, I posted some tickets about it and they were fixed immediately. Also, XHTML-IM supported in tkabber, but it's implemented in the way that makes it better to switch it off. (maybe it was fixed, I don't know) and pidgin has the worst support of XHTML-IM: it always renders the message in one line even if it has paragraphs or lists or any other block element. I use the XEP-0071 in my microblogging, can attach some screenshots: Psi: http://jawiki.ru/images/4/44/Psi-lij.png http://jawiki.ru/File:Hh-case1-reply.png Gajim: http://jrudevels.org/Trash/gajim-lijuick-lor-gallery.png 2. Have developers experienced any problems with the protocol as defined in XEP-0071? If so, please describe the problems and, if possible, suggested solutions. 3. Is the text of XEP-0071 clear and unambiguous? Are more examples needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. Why don't we have a possibility to use the del HTML tag? The other things I will describe in an answer to Mathieu Pasquet. If you have any comments about advancing XEP-0071 from Draft to Final, please provide them by the close of business on Friday, August 31, 2012. After the Call for Experience, this XEP might undergo revisions to address feedback received, after which it will be presented to the XMPP Council for voting to a status of Final. You can review the specification here: http://www.xmpp.org/extensions/xep-0071.html Please send all feedback to the standards@xmpp.org discussion list. Thanks! Peter -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
Hello. On 08/01/2012 07:43 AM, Mathieu Pasquet wrote: I am also not sure about the strong/ and blockquote/ elements: they are shown as a recommended element to support (7.8), but the business rules (8.7) states that they should not be used, but rather span/ or p/ with appropriate style attributes. Is it only for backward compatibility, then? I'm using the blockquote element very intensive. I don't think that we should give a preference to style attributes because IM differs from web and we need messages to be more semantic than to be more styled. I.e. we need to support the same style for all messages as strong as it possible to prevent transformation of a chat window to an Xmas tree, so we need to outline semantic groups rather than style them to provide a possibility to theme them by recipient preference. Also, it's easier to parse such message by machines to provide some advance search possibilities and etc. So I don't imagine the XHTML-IM without such things as blockquote, cite, code, strong, em, etc. There is the matter of the img/ tag that accepts a data:base64 as a src, leading to very big stanzas. I think that maybe the XEP could state that whenever possible, the use of base64 data should be avoided, at least in MUCs, where the message is replicated as many times as there are users, leading to high bandwith usage (although if I remember correctly, most servers set the max stanza size to 10 KiB). agree. possibly, we need to prefer XEP-231 for that? Also, I am dreaming of some flexible file sharing protocol through XMPP to be able to transfer bigger files that's possible with XEP-231. -- Mathieu Pasquet (mathieui) Nice to meet you, Mathieu. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
On 7/31/12 2:58 PM, Peter Saint-Andre wrote: If you have any comments about advancing XEP-0071 from Draft to Final, please provide them by the close of business on Friday, August 31, 2012. Section 12.4 of XEP-0071 (version 1.4) reads in full: ### 12.4 W3C Review The XHTML 1.0 Integration Set defined herein has been reviewed informally by an editor of the XHTML Modularization in XML Schema specification but has not undergone formal review by the W3C. Before the XHTML-IM specification proceeds to a status of Final within the standards process of the XMPP Standards Foundation, the XMPP Council is encouraged to pursue a formal review through communication with the Hypertext Coordination Group within the W3C. ### Although I would in fact like to obtain such a formal W3C review, I don't think it's realistic to make formal W3C review a gating factor for advancement to Final because the folks who work on HTML at the W3C are very busy with HTML5 (and will be for the foreseeable future as far as I can see). Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
Is the text of XEP-0071 clear and unambiguous? Are more examples needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. 7.6 states that the style attribute MUST be supported, but 7.6.1 on the other hand shows a list of RECOMMENDED CSS1 properties. If a client does not implement any of those properties, isn’t it the same as dropping the style attribute (and therefore not supporting it)? I am also not sure about the strong/ and blockquote/ elements: they are shown as a recommended element to support (7.8), but the business rules (8.7) states that they should not be used, but rather span/ or p/ with appropriate style attributes. Is it only for backward compatibility, then? There is the matter of the img/ tag that accepts a data:base64 as a src, leading to very big stanzas. I think that maybe the XEP could state that whenever possible, the use of base64 data should be avoided, at least in MUCs, where the message is replicated as many times as there are users, leading to high bandwith usage (although if I remember correctly, most servers set the max stanza size to 10 KiB). Finally, although we have a somehow working partial implementation of XEP-0071 in Poezio, I wouldn’t count it as a proper codebase for XEP validation, because the limitations of console clients do not allow a full implementation (e.g. font changes, text-decorations other than underline, relative margins, etc). -- Mathieu Pasquet (mathieui) signature.asc Description: OpenPGP digital signature
