Subject: RE: [Simple] Comments on draft-ietf-simple-future

From: "Brian Stucker" <[email-masked]>
Date: Mon, 1 Mar 2004 10:19:40 -0600

On a similar note... I didn't want to bring this up during the meeting today
because of the compressed schedule, but are we really happy with using
absolute time stamps? I'm a bit worried about using them when we've gone
back and gotten rid of them elsewhere in the protocol. Am I just being
paranoid?

Regards,

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, March 01, 2004 9:09 AM
To: Paul Kyzivat
Cc: Simple WG
Subject: Re: [Simple] Comments on draft-ietf-simple-future

Paul Kyzivat wrote:

> 
> 
> Jonathan Rosenberg wrote:
> 
>>>  Future status cannot be expressed with <tuples> elements with
>>>    optional extensions since PIDF parsers would not be able to
>>>    distinguish current from future or past information.
>>
>>
>>
>> I think you mean <tuple> elements. In any case, this text is not quite 
>> right. You are in fact extending <tuple> with an optional extension, 
>> <future-status>. What I think you mean is that you cannot just extend 
>> an existing element, like <activity>, with attributes that define the 
>> future status, because these would not be understood and thus 
>> misinterpreted as current status.
> 
> 
> Not only can't, but don't want to. The goal is to provide a way to use 
> all the normal attributes that define current status to define future 
> status as well. So the goal is to provide a separate context in which 
> the existing elements may be used where they won't be misunderstood by 
> those who don't understand this extension.
> 
>> Unfortunately, the nature of the schemas is that the new one cannot 
>> say where in the PIDF document this is supposed to go. You need to 
>> specify that this element MUST be a child of <tuple>. Also, can you 
>> have more than one (I think so)? In that case, can they represent 
>> overlapping times (I think so)?
> 
> 
> That is an ugly case, because when there is an overlap, which takes 
> precedence?

I had in mind cases where the attributes in the overlapping time-spaces 
themselves did not overlap, e.g., i was <busy> from 10am-11am and <in a 
meeting> from 1030am to noon.

I suppose we could just mandate that the PA only generate notifications 
with non-overlapping intervals. This forces the PA to do any kind of 
precedence computations. I think the PA is the only one that can do it.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Mar 2004 11:36:45 -0500

Yes, I think you need them.

The reason is that, if you used relative timestamps, then the timestamps 
need to be recomputed every time the presence document is fetched or 
sent in a notify. This requires a "re-encoding" of the document into XML 
from whatever internal form is being used, and ends up being very 
expensive. Plus, without absolute timestamps, the document doesnt stand 
on its own. It would only be defined relative to the time of delivery in 
a transport protocol. That would prohibit me from putting such a doc on 
a web page, if I so desired (for example).

-Jonathan R.

Brian Stucker wrote:

> On a similar note... I didn't want to bring this up during the meeting 
> today because of the compressed schedule, but are we really happy with 
> using absolute time stamps? I'm a bit worried about using them when 
> we've gone back and gotten rid of them elsewhere in the protocol. Am I 
> just being paranoid?
> 
> Regards,
> 
> Brian
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Mar 2004 11:36:45 -0500

-Jonathan R.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 03 Mar 2004 09:32:38 +0900

I agree. Further, if I recall correctly, the main reason we have tried 
to get rid of absolute times elswhere is because of clock sync issues, 
isn't it? Future presence times should not require a high level of 
accuracy. As long as clocks are in vague agreement, we should be okay.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 03 Mar 2004 09:32:38 +0900