[Standards-JIG] proto-JEP: Time Periods

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Mon Mar 21 18:53:21 UTC 2005

Hi Ralph,

We have to consider that this JEP is giving us the possibility to further
qualify an event with a time period. In its current form, I believe it is up
to the task. And I thank Peter for the quick turn around.

As a more general point, I feel that we must be wary of interpreting
examples given in JEPs or following them to the letter. I would be very much
in favor of adding a note to JEP examples to clearly indicate when they are
only 'informative' or 'normative'. Doing so will probably ease up some of
our discussions ;)

One way to further enhance our process would be to write separate use cases
for different protocol JEPs applications. Similar constructs may be used in
very different cases, and it is a good approach to detail them when a new
application trend is shaping up. 



P.S. BTW, another part of the industry has a different view about the
relationship between 'presence' and 'time period' It's probably a matter of

-----Original Message-----
Message: 2
Date: Mon, 21 Mar 2005 10:34:20 +0100
From: Ralph Meijer <jabber.org at ralphm.ik.nu>
Subject: Re: [Standards-JIG] proto-JEP: Time Periods
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <20050321093420.GA24444 at ik.nu>
Content-Type: text/plain; charset=us-ascii

On Thu, Mar 17, 2005 at 02:56:48PM -0600, Peter Saint-Andre wrote:
> On Thu, Mar 17, 2005 at 02:54:09PM -0600, JEP Editor wrote:
> > The JEP Editor has received a proposal for a new JEP.
> > 
> > Title: Time Periods
> > 
> > Abstract: This proposal defines how to specify time periods for events
and states communicated in XMPP and XMPP extensions.
> > 
> > URL: http://www.jabber.org/jeps/inbox/timeperiod.html
> That's all I had time for today and I have some other stuff to crank
> out, so I figured I would publish what I had. Comments welcome as
> always.

Good beginning, but I dislike all examples :-)

In general, I think that sending along a start time for presence, and
presence sent using pubsub with an ItemID of 'current' makes little sense.
are dealing with a near-realtime communication medium. I can think of two

 - Notifications that are delivered some time after the actual publish, but
   this would be something that could be changed by resp. the server and
   service. Of course, jabber:x:delay comes into mind here as well.

 - Automatic away/xa. One could use timeperiod for conveying the beginning
   inactivity (which is before sending the presence!).

For pubsub, I think I'd like it better if this extension would be a direct
child of the <item/>.




Standards-JIG mailing list
Standards-JIG at jabber.org

End of Standards-JIG Digest, Vol 14, Issue 23

More information about the Standards mailing list