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: "Brian Stucker" <[email-masked]>
Date: Mon, 1 Mar 2004 16:40:45 -0600

Yeah, ok. That's a valid point.

Thanks,

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, March 01, 2004 10:37 AM
To: Stucker, Brian [NGC:B617:EXCH]
Cc: Paul Kyzivat; Simple WG
Subject: Re: [Simple] Comments on draft-ietf-simple-future

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: "Brian Stucker" <[email-masked]>
Date: Mon, 1 Mar 2004 16:40:45 -0600

Thanks,

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, March 01, 2004 10:37 AM
To: Stucker, Brian [NGC:B617:EXCH]
Cc: Paul Kyzivat; Simple WG
Subject: Re: [Simple] Comments on draft-ietf-simple-future

-Jonathan R.

---

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

---

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:

> 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: "Brian Stucker" <[email-masked]>
Date: Wed, 3 Mar 2004 00:00:35 -0600

I don't see this as being "could be useful". I know of many people that
regularly
 double-book meetings for instance, where one is clearly less important than
the other. If given a list of possible statuses, does it not make sense that
IF the user or some other process knows that one status is very likely less
important (or correct) than another, there be a way to signify this. Even if
all of the statuses are displayed, it's somewhat sterile information, and
we're saying the only way to know which one is likely more important (or
even what order in which they should be considered) has to be in the text of
the status somewhere, where machines can't get at it.

Regards,

Brian

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

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.

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 3 Mar 2004 00:00:35 -0600

Regards,

Brian