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

From: "Brian Stucker" <[email-masked]>
Date: Tue, 2 Mar 2004 23:12:15 -0600

I would agree with Henning on this. However, this does give rise to
non-deterministic information. What would the renderer of this information
wind up showing? In the case of overlapping statuses, do we need to provide
the ability (but not necessarily the requirement that it be used) to put
something of a Q value along with the status. If no Q value is provided, the
render can do whatever it wants... display everything, the first one, the
last one, or whatever (because there's no indication as to which one is
"better" than the other).

Regards,

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Tuesday, March 02, 2004 11:03 PM
To: Paul Kyzivat
Cc: Jonathan Rosenberg; Simple WG
Subject: Re: [Simple] Comments on draft-ietf-simple-future

It is quite common that calendars have overlapping appointments, due to 
user error, intent to leave early or optimism that one appointment will 
end earlier as scheduled. I don't see how a PA can resolve what a human 
cannot or chose not to.

Paul Kyzivat wrote:

>> 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.
> 
> 
> Your example of overlapping time ranges for orthogonal attributes is a 
> good one. I don't think we would want to forbid that.
> 
> But maybe we could forbid overlapping time ranges containing an instance 
> of the same element.
> 
>     Paul
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Mar 2004 00:47:51 -0500

I'm wary of over-engineering this problem and trying to use parameters 
to deal with the messiness and uncertainties of real life. It seems like 
calendaring programs simply display all the information, possibly using 
shading or layout to indicate such overlap, and let the user figure out 
that there is indeed uncertainty. I don't see how adding a parameter 
adds more than complexity.

Brian Stucker wrote:

> non-deterministic information. What would the renderer of this 
> information wind up showing? In the case of overlapping statuses, do we 
> need to provide the ability (but not necessarily the requirement that it 
> be used) to put something of a Q value along with the status. If no Q 
> value is provided, the render can do whatever it wants... display 
> everything, the first one, the last one, or whatever (because there's no 
> indication as to which one is "better" than the other).
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Mar 2004 00:47:51 -0500

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Mar 2004 03:03:21 -0500

Henning has me convinced that you can't ban this from the document. I 
think this becomes an area where clients can get creative with how they 
present this sort of conflicting information.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Mar 2004 03:03:21 -0500

Paul