[Standards] Standards Digest, Vol 56, Issue 16

e.edua at yahoo.com e.edua at yahoo.com
Wed Jul 16 13:55:33 UTC 2008



On Jul 15, 2008, at 5:45 AM, standards-request at xmpp.org wrote:

Send Standards mailing list submissions to
   standards at xmpp.org

To subscribe or unsubscribe via the World Wide Web, visit
   http://mail.jabber.org/mailman/listinfo/standards
or, via email, send a message with subject or body 'help' to
   standards-request at xmpp.org

You can reach the person managing the list at
   standards-owner at xmpp.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Standards digest..."


Today's Topics:

  1. another special-purpose list: mobile at xmpp.org (Peter Saint-Andre)
  2. OT [Fwd: Reminder: Jabber Server Load Test Tomorrow]
     (Peter Saint-Andre)
  3. Re: thread destruction (Peter Saint-Andre)


----------------------------------------------------------------------

Message: 1
Date: Mon, 14 Jul 2008 14:44:22 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Subject: [Standards] another special-purpose list: mobile at xmpp.org
To: XMPP Extension Discussion List <standards at xmpp.org>,    Jabber/XMPP
   software development list <jdev at jabber.org>
Message-ID: <487BBAA6.8020907 at stpeter.im>
Content-Type: text/plain; charset="iso-8859-1"

I've created another special-purpose discussion list, this one for 
mobile applications and optimizations of XMPP technologies. Naturally 
enough it's called mobile at xmpp.org:

http://mail.jabber.org/mailman/listinfo/mobile

Tell all your friends!

/psa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080714/2eb38845/attachment-0001.bin 

------------------------------

Message: 2
Date: Mon, 14 Jul 2008 16:52:34 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Subject: [Standards] OT [Fwd: Reminder: Jabber Server Load Test
   Tomorrow]
To: XMPP Extension Discussion List <standards at xmpp.org>,    Jabber/XMPP
   software development list <jdev at jabber.org>
Message-ID: <487BD8B2.2050607 at stpeter.im>
Content-Type: text/plain; charset="iso-8859-1"

FYI in case anyone would like to help the IETF test their new XMPP 
service. :)

-------- Original Message --------
Date: Mon, 14 Jul 2008 14:41:05 -0700
Subject: Reminder: Jabber Server Load Test Tomorrow
From: Alexa Morris <amorris at amsl.com>
To: ietf-announce at ietf.org <ietf-announce at ietf.org>

As noted last week, we recently deployed a new IETF Jabber server
(ejabbered) and we would like to load test it before the Dublin meeting.
Tomorrow, Tuesday, July 15 at 10am PT (1PM ET and 5pm GMT) you are
officially invited to log into the IETF Jabber Hallway or various WG
Chatrooms and chat with your fellow community members. We will be monitoring
the performance of the server from 10-11am PT, so the more people online and
using the Jabber Chatrooms the better.

For more information about the IETF Jabber services, please see here:
http://jabber.ietf.org/

Thank you,
Alexa

-----------
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: amorris at amsl.com

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com <http://www.amsl.com/>



_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080714/6e79a62a/attachment-0001.bin 

------------------------------

Message: 3
Date: Tue, 15 Jul 2008 06:28:10 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Subject: Re: [Standards] thread destruction
To: XMPP Extension Discussion List <standards at xmpp.org>
Message-ID: <487C97DA.2090806 at stpeter.im>
Content-Type: text/plain; charset="iso-8859-1"

Peter Saint-Andre wrote:
Someone pointed out to me the following discrepancy between
XEP-0085 and XEP-0201...

XEP-0085 says:

  Upon receiving a <gone/> event, a client MUST NOT re-use
  the same Thread ID and MUST generate a new Thread ID for
  any subsequent chat messages sent to the conversation
  partner.

BTW the <gone/> state is defined as follows:

***

User has not interacted with the chat interface, system, or device for a 
relatively long period of time (e.g., 2 minutes), or has terminated the 
chat interface (e.g., by closing the chat window).

***

XEP-0201 says:

  An entity ... SHOULD NOT destroy the thread if a human
  user merely disengages from the chat session (e.g., by
  closing a window in a client interface).

Clearly these two recommendations are in conflict, so we need
to reconcile them. I'm not yet sure which way I lean.

Feedback is welcome.

Seeing no feedback, I'll weigh in. :)

XEP-0085 defines the protocol for chat state notifications. When we 
defined that protocol, it made sense to say that a thread is tied to a 
chat interface because the protocol is all about whether the person 
you're chatting with in a one-to-one chat session is paying attention to 
the chat interface. (Yes, XEP-0085 makes a passing mention of chat state 
notifications in groupchat rooms, but the focus is on one-to-one chat 
sessions.)

XEP-0201 talks about threads in general, not threads in relation to chat 
interfaces or one-to-one chat sessions. In particular, one of the ideas 
behind XEP-0201 is that a thread might last across XMPP sessions, and 
certainly that a conversation can continue after a chat interface has 
been destroyed. [IIRC, we started to work on XEP-0201 after we realized 
that the concept of a "conversation" was not clear in XEP-0136 (Message 
Archiving) and XEP-0155 (Stanza Session Negotiation).]

Another input is the concept of a "chat session" from rfc3921bis. There 
I defined a chat session as a somewhat large number of messages sent 
within a relatively brief period of time -- a kind of conversational 
burst, if you will.

Now, I realize that all these ideas are somewhat vague, but that's 
because we can't neatly demarcate a chat session as (say) more than 10
messages exchanged in less than 5 minutes. We all engage in chat 
sessions every day, and we know them when we're in them, but there is no 
hard-and-fast definition of a chat session. Furthermore, if we map (say) 
newsgroup or web forum messages to XMPP messages of type "normal" then 
clearly threads can last across XMPP sessions. And that's not even to 
mention threads in groupchat rooms, where you might have more than one 
conversation thread happening at once.

Clearly, threads can mean different things in the context of different 
message types, and if we're going to define thread handling we need to 
think about what threads mean for messages of type "chat", "groupchat", 
"normal", and even "headline". However, even in the context of "chat" 
messages I think the rule "MUST destroy the thread when you receive a 
<gone/> event" in XEP-0085 is too strong. Unfortunately, the rule 
"SHOULD NOT destroy the thread if the other party disengages from the 
chat interface" in XEP-0201 is merely negative and doesn't provide any 
positive guidance to client developers about when to generate a new 
thread ID.

So my conclusion is that further thought is required. :)

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080715/3c79cebf/attachment.bin 

------------------------------

_______________________________________________
Standards mailing list
Standards at xmpp.org
http://mail.jabber.org/mailman/listinfo/standards


End of Standards Digest, Vol 56, Issue 16
*****************************************



      




More information about the Standards mailing list