Re: [Standards] XEP-0301 -- embedding small illustrative animated GIF into spec

[Mark Rejhon]

On 2012-08-01 11:15 AM, "Peter Saint-Andre"  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I was suggesting that we host the image at xmpp.org but not embed it
> in the document -- I don't particularly want an animated GIF in the
> middle of the spec, but I'd like to have a stable URL we can point to.

Aha, that would satisfy the concerns of M&M too.  The same question about
image criteria, applies, except maybe size is more flexible now.

There is no precedent that I am aware of, for this practice, is there?

Mark

Re: [Standards] XEP-0301 -- embedding small illustrative animated GIF into spec

[Mark Rejhon]

On 2012-08-01 11:08 AM, "Matthew Miller"  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I have concerns embedding something into a document that reduces its
printability.  As archaic as this sounds, I often print specifications in
order to review them!
>
> That said, I'm not immediately opposed to it, but would approach with
caution. The text is still the record of authority here.

Gotcha.  Anyone else opposed, and prefer I refer to realtimetext.org only?
The text already written, will continue to be an authority in attempting to
explain real time text in less than a thousand words in the Introduction
paragraph :-)

A strategic first-frame (the frame that normally gets printed by all major
browsers) may show both sender/recipients aware of each other's typing.  It
would mean the animation essentially starts mid-conversation, but it can
also loop. (After a delay, or a maximum loop count)

The image would be somewhere in Introduction, the first anyone may read
even before printing, and serve the "aha, that is what it is" purpose. The
words will continue to try its best, so the spec can be used without the
image.

Then again, contuing to referencing a website for animation has other
merits (pros and cons)

I'll go with what XSF is most likely to prefer, in general.  It is indeed,
a technology, that even a 5 second animation benefits.
On 2012-08-01 11:08 AM, "Matthew Miller"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I have concerns embedding something into a document that reduces its
> printability.  As archaic as this sounds, I often print specifications in
> order to review them!
>
> That said, I'm not immediately opposed to it, but would approach with
> caution. The text is still the record of authority here.
>
>
> - - m&m
>
> Matthew A. Miller
> 
>
> On Aug 1, 2012, at 07:46, Mark Rejhon wrote:
>
> > Note: Precedent on image embeds exists -- an example image is embedded
> into
> > XHTML-IM (XEP-0071).
> >
> > On 2012-08-01 8:53 AM, "Peter Saint-Andre"  wrote:
> >>
> >> On 7/23/12 1:17 PM, Mark Rejhon wrote:
> >>
> >>> [Question]
> >>> Understood -- animation really helps explains real-time text, if they
> >>> haven't seen it before.
> >>> Can we use a more well-known site (i.e. realtimetext.org
> >>> ?) since we can put my animations there too?
> >>> Alternatively, can we embed an image, like XEP-0071 has an embedded
> >>> image?  (If I make a generic animation, and convert it to animated GIF
> >>> format)
> >>
> >> I think it would be great to host a sample animated GIF at xmpp.org,
> for
> >> archival purposes.
> >
> > For now, I have switched it to realtimetext.org in the already-published
> > v0.6, but an embed (found in certain XEP's) would be even more
> preferable,
> > though it obviously would have to be very small and very generic, which
> > probably requires it to be hand-made or a special RealJabber mod.
> >
> > Examples animations I have already made, which are probably not suitable,
> > but useful to see:
> >
> > 1. My animation of key press intervals
> > http://www.realjabber.org/anim/real_time_text_demo.html
> > - too big
> > - too non-generic
> >
> > 2. Facebook-style concept animation
> > http://www.realjabber.org/anim/facebook_chat_concept.gif
> > - closer to correct size
> > - but too non-generic
> >
> > 3. The animation on cover page
> > http://www.realjabber.org
> > - still too non-generic
> > - this was my first animation ever
> >
> > So, that means:
> > As I will have to hand-make a genericization (something suitable even
> for a
> > Wikipedia page, for the 'real-time text' entry)...
> > ...If no other people at XSF objects technically to an image embed, what
> > are the recommended criteria for an image embed in XEP-0301 demoing
> generic
> > real time text:
> > - minimal GUI elements (OS neutral)
> > - small size
> > - romeo/juliet names (recommended)
> > - no cuecard introduction frame
> > - compatible open source imagery only
> >
> > Mark Rejhon
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQEcBAEBAgAGBQJQGUZeAAoJEJq6Ou0cgrSPaSoIAMPf/LuE+8BglAnKF9ZvIl8+
> BZxWsjKjsncS9tPU4WzE8dLSwW2eEilFU9jc0YXfJEwmwOmattPvQBYrdy16T6r7
> Csc3Zcrm9gRDI5I1cAvUtcIBpFoI5njdYqf68yQQU1U06BGkBHldKf1t1JU/bi9F
> 8zn8CcurwR5U1Fd1D1jMLLmv2Yb0ij79boT1qDc1ilAhClz4+zvFTvsYuksLT+vR
> JB+A3kv57Pc7/7cj1TxYjHQT4RN7ABHN25kdwhu7h15Qn4Yav9SeVLTNFedCY3ke
> s8WzecA8IfzBpt8kfyyzJB1rNaLA6AmFdf3OPEO7PNHvNkK1Ftgw+ZbOeQFsAds=
> =fB3j
> -END PGP SIGNATURE-
>

Re: [Standards] XEP-0301 -- embedding small illustrative animated GIF into spec

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I was suggesting that we host the image at xmpp.org but not embed it
in the document -- I don't particularly want an animated GIF in the
middle of the spec, but I'd like to have a stable URL we can point to.

On 8/1/12 9:08 AM, Matthew Miller wrote:
> I have concerns embedding something into a document that reduces
> its printability.  As archaic as this sounds, I often print
> specifications in order to review them!
> 
> That said, I'm not immediately opposed to it, but would approach
> with caution. The text is still the record of authority here.
> 
> 
> - m&m
> 
> Matthew A. Miller 
> 
> On Aug 1, 2012, at 07:46, Mark Rejhon wrote:
> 
>> Note: Precedent on image embeds exists -- an example image is
>> embedded into XHTML-IM (XEP-0071).
> 
>> On 2012-08-01 8:53 AM, "Peter Saint-Andre" 
>> wrote:
>>> 
>>> On 7/23/12 1:17 PM, Mark Rejhon wrote:
>>> 
 [Question] Understood -- animation really helps explains
 real-time text, if they haven't seen it before. Can we use a
 more well-known site (i.e. realtimetext.org 
 ?) since we can put my animations
 there too? Alternatively, can we embed an image, like
 XEP-0071 has an embedded image?  (If I make a generic
 animation, and convert it to animated GIF format)
>>> 
>>> I think it would be great to host a sample animated GIF at
>>> xmpp.org, for archival purposes.
> 
>> For now, I have switched it to realtimetext.org in the
>> already-published v0.6, but an embed (found in certain XEP's)
>> would be even more preferable, though it obviously would have to
>> be very small and very generic, which probably requires it to be
>> hand-made or a special RealJabber mod.
> 
>> Examples animations I have already made, which are probably not
>> suitable, but useful to see:
> 
>> 1. My animation of key press intervals 
>> http://www.realjabber.org/anim/real_time_text_demo.html - too
>> big - too non-generic
> 
>> 2. Facebook-style concept animation 
>> http://www.realjabber.org/anim/facebook_chat_concept.gif - closer
>> to correct size - but too non-generic
> 
>> 3. The animation on cover page http://www.realjabber.org - still
>> too non-generic - this was my first animation ever
> 
>> So, that means: As I will have to hand-make a genericization
>> (something suitable even for a Wikipedia page, for the 'real-time
>> text' entry)... ...If no other people at XSF objects technically
>> to an image embed, what are the recommended criteria for an image
>> embed in XEP-0301 demoing generic real time text: - minimal GUI
>> elements (OS neutral) - small size - romeo/juliet names
>> (recommended) - no cuecard introduction frame - compatible open
>> source imagery only
> 
>> Mark Rejhon
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAZSCYACgkQNL8k5A2w/vyA4QCeJlBndsU9Qr0swBFzCvA9JrJu
megAoI7Bg0+qBys08rLyyNMxj0oLPV8C
=3+TF
-END PGP SIGNATURE-

Re: [Standards] XEP-0301 -- embedding small illustrative animated GIF into spec

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have concerns embedding something into a document that reduces its 
printability.  As archaic as this sounds, I often print specifications in order 
to review them!

That said, I'm not immediately opposed to it, but would approach with caution. 
The text is still the record of authority here.


- - m&m

Matthew A. Miller


On Aug 1, 2012, at 07:46, Mark Rejhon wrote:

> Note: Precedent on image embeds exists -- an example image is embedded into
> XHTML-IM (XEP-0071).
> 
> On 2012-08-01 8:53 AM, "Peter Saint-Andre"  wrote:
>> 
>> On 7/23/12 1:17 PM, Mark Rejhon wrote:
>> 
>>> [Question]
>>> Understood -- animation really helps explains real-time text, if they
>>> haven't seen it before.
>>> Can we use a more well-known site (i.e. realtimetext.org
>>> ?) since we can put my animations there too?
>>> Alternatively, can we embed an image, like XEP-0071 has an embedded
>>> image?  (If I make a generic animation, and convert it to animated GIF
>>> format)
>> 
>> I think it would be great to host a sample animated GIF at xmpp.org, for
>> archival purposes.
> 
> For now, I have switched it to realtimetext.org in the already-published
> v0.6, but an embed (found in certain XEP's) would be even more preferable,
> though it obviously would have to be very small and very generic, which
> probably requires it to be hand-made or a special RealJabber mod.
> 
> Examples animations I have already made, which are probably not suitable,
> but useful to see:
> 
> 1. My animation of key press intervals
> http://www.realjabber.org/anim/real_time_text_demo.html
> - too big
> - too non-generic
> 
> 2. Facebook-style concept animation
> http://www.realjabber.org/anim/facebook_chat_concept.gif
> - closer to correct size
> - but too non-generic
> 
> 3. The animation on cover page
> http://www.realjabber.org
> - still too non-generic
> - this was my first animation ever
> 
> So, that means:
> As I will have to hand-make a genericization (something suitable even for a
> Wikipedia page, for the 'real-time text' entry)...
> ...If no other people at XSF objects technically to an image embed, what
> are the recommended criteria for an image embed in XEP-0301 demoing generic
> real time text:
> - minimal GUI elements (OS neutral)
> - small size
> - romeo/juliet names (recommended)
> - no cuecard introduction frame
> - compatible open source imagery only
> 
> Mark Rejhon

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQGUZeAAoJEJq6Ou0cgrSPaSoIAMPf/LuE+8BglAnKF9ZvIl8+
BZxWsjKjsncS9tPU4WzE8dLSwW2eEilFU9jc0YXfJEwmwOmattPvQBYrdy16T6r7
Csc3Zcrm9gRDI5I1cAvUtcIBpFoI5njdYqf68yQQU1U06BGkBHldKf1t1JU/bi9F
8zn8CcurwR5U1Fd1D1jMLLmv2Yb0ij79boT1qDc1ilAhClz4+zvFTvsYuksLT+vR
JB+A3kv57Pc7/7cj1TxYjHQT4RN7ABHN25kdwhu7h15Qn4Yav9SeVLTNFedCY3ke
s8WzecA8IfzBpt8kfyyzJB1rNaLA6AmFdf3OPEO7PNHvNkK1Ftgw+ZbOeQFsAds=
=fB3j
-END PGP SIGNATURE-

Re: [Standards] XEP-0301 -- embedding small illustrative animated GIF into spec

[Mark Rejhon]

Note: Precedent on image embeds exists -- an example image is embedded into
XHTML-IM (XEP-0071).

On 2012-08-01 8:53 AM, "Peter Saint-Andre"  wrote:
>
> On 7/23/12 1:17 PM, Mark Rejhon wrote:
>
> > [Question]
> > Understood -- animation really helps explains real-time text, if they
> > haven't seen it before.
> > Can we use a more well-known site (i.e. realtimetext.org
> > ?) since we can put my animations there too?
> >  Alternatively, can we embed an image, like XEP-0071 has an embedded
> > image?  (If I make a generic animation, and convert it to animated GIF
> > format)
>
> I think it would be great to host a sample animated GIF at xmpp.org, for
> archival purposes.

For now, I have switched it to realtimetext.org in the already-published
v0.6, but an embed (found in certain XEP's) would be even more preferable,
though it obviously would have to be very small and very generic, which
probably requires it to be hand-made or a special RealJabber mod.

Examples animations I have already made, which are probably not suitable,
but useful to see:

1. My animation of key press intervals
http://www.realjabber.org/anim/real_time_text_demo.html
- too big
- too non-generic

2. Facebook-style concept animation
http://www.realjabber.org/anim/facebook_chat_concept.gif
- closer to correct size
- but too non-generic

3. The animation on cover page
http://www.realjabber.org
- still too non-generic
- this was my first animation ever

So, that means:
As I will have to hand-make a genericization (something suitable even for a
Wikipedia page, for the 'real-time text' entry)...
...If no other people at XSF objects technically to an image embed, what
are the recommended criteria for an image embed in XEP-0301 demoing generic
real time text:
- minimal GUI elements (OS neutral)
- small size
- romeo/juliet names (recommended)
- no cuecard introduction frame
- compatible open source imagery only

Mark Rejhon

Re: [Standards] XEP-0301 0.5 comments [Sections 1 through 5]

[Peter Saint-Andre]

On 7/27/12 8:19 AM, Mark Rejhon wrote:

 "The event attribute MAY be omitted from the  element during
 regular real-time text transmission" - what is the the alternative
 you're allowing clients, and what is "regular real-time text
 transmission"?
>>>
>>> [Change made]
>>> Clarification made: "The event attribute is NOT required for  when
>>> transmitting changes to an existing real-time message."
>>
>> I'm not fond of either MAY or not required here - it seems like the
>> behaviour isn't optional in any way, but firmly defined depending on
>> the content of the stanza. It's not immediately clear to me what the
>> right wording is, but it seems like it should be tighter.
> 
> [Comment]
> (c/NOT required/NOT REQUIRED/)
> Basic Real-Time Text allows you to transmit message changes via
> Message Reset, so there are situations where you're always using an
> 'event' attribute for all  elements.
> How can the wording be tweaked, so that circumstance is accomodated for?

There's no such thing as NOT REQUIRED in RFC 2119. I suggest changing it
to "The event attribute is not necessary..."

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: [Standards] XEP-0301 0.5 comments [Sections 1 through 5]

[Peter Saint-Andre]

On 7/23/12 1:17 PM, Mark Rejhon wrote:

> [Question]
> Understood -- animation really helps explains real-time text, if they
> haven't seen it before.
> Can we use a more well-known site (i.e. realtimetext.org
> ?) since we can put my animations there too?
>  Alternatively, can we embed an image, like XEP-0071 has an embedded
> image?  (If I make a generic animation, and convert it to animated GIF
> format)

I think it would be great to host a sample animated GIF at xmpp.org, for
archival purposes.

> /P.S. Will inquire about the name concern (private inquiry to Peter).  I
> had talked to many at Cisco over the last two years. Paul E. Jones is a
> a member of R3TF who works at Cisco.  Nobody has ever brought up concern
> about the RealJabber name, but I will now inquire specifically about this./

Just because someone works at Cisco doesn't mean they would have any
awareness of the JABBER trademark. But we can chat about that off-list.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

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

[Sergey Dobrov]

Hello.

On 08/01/2012 07:43 AM, Mathieu Pasquet wrote:
> 
> I am also not sure about the  and  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  or
>  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  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

[Sergey Dobrov]

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  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  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.