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

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

I'm thinking about the case where you have a limited display form-factor,
where you can't easily display both. Is this really adding that much
complexity? I'm not suggesting that it MUST or even SHOULD be used, but MAY
be used.

Regards,

Brian

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

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:

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

---

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

Brian Stucker wrote:

> I'm thinking about the case where you have a limited display 
> form-factor, where you can't easily display both. Is this really adding 
> that much complexity? I'm not suggesting that it MUST or even SHOULD be 
> used, but MAY be used.

I just see no realistic way to add this in most cases. Unless this is 
available in all contexts, the UI has to be able to deal with the case 
where it isn't there.

I'd really like to avoid adding "could be useful" features.

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

---

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