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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Mar 2004 10:08:53 -0500

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 10:08:53 -0500

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2004 00:06:05 -0500

> 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: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2004 00:06:05 -0500

Paul

---

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

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

---

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 05 Mar 2004 08:10:26 -0500

> those who don't understand this extension.

I clarified the wording (I hope).

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 05 Mar 2004 08:10:26 -0500

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 05 Mar 2004 08:29:32 -0500

Thanks for your comments. I think I addressed all of them; brief remarks 
in-line.

Jonathan Rosenberg wrote:

> 
> I think you need to be a bit more specific here about the procedure that 
> is to be followed. Furthermore, I think that a sanity check on time sync 
> should be more than just "advice to implementors", and rather should be 
> SHOULD strength.

SHOULD and a bit more checking detail added, although I can't think of 
anything beyond the notification timestamp, making sure that the time 
range is not spanning the present and that it is outside the range in 
the <timestamp> PIDF element.

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

Added verbiage that senders of timed-status are to avoid overlapping 
elements, that this isn't always possible but that receivers MUST be 
able to handle this.

> 
> Also, the schema does not indicate any specific RPID elements which can 
> sensibly included within future-status. I think those should be defined 
> here by referencing them in the future-status schema from the rpid 
> schema. Indeed, presumably any PIDF extension that can appear within 
> <status> can also appear within <future-status>; you should probably 
> mention that. Some, I suspect, won't be that useful practically speaking 
> (for example, <relationship>), and the text should probably give some 
> guidance about that.

<relationship> should be a tuple element, I think. I'm not sure whether 
I should enumerate all the RPID elements that don't make sense. Even 
idle can be construed to be useful, for example, if a compositor has 
only old information from a device, including the last idle time. I have 
noted, by example, that CIPID is not useful.

As a side note, maybe the usefulness in timed-status is a good 
indication that something really extends <tuple> not <status>.
> Thanks,
> Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 05 Mar 2004 08:29:32 -0500

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Mar 2004 14:06:21 -0500

inline.

Henning Schulzrinne wrote:

>> I think you need to be a bit more specific here about the procedure 
>> that is to be followed. Furthermore, I think that a sanity check on 
>> time sync should be more than just "advice to implementors", and 
>> rather should be SHOULD strength.
> 
> 

That seems fine.

> elements, that this isn't always possible but that receivers MUST be 

OK.

> 
> 
>>
>> Also, the schema does not indicate any specific RPID elements which 
>> can sensibly included within future-status. I think those should be 
>> defined here by referencing them in the future-status schema from the 
>> rpid schema. Indeed, presumably any PIDF extension that can appear 
>> within <status> can also appear within <future-status>; you should 
>> probably mention that. Some, I suspect, won't be that useful 
>> practically speaking (for example, <relationship>), and the text 
>> should probably give some guidance about that.
> 
> 
> <relationship> should be a tuple element, I think.

Yes, that makes sense.

> I'm not sure whether 
> I should enumerate all the RPID elements that don't make sense. 

There aren't that many; the more you can say the better, I think.

> Even 

I don't understand idle time. If I know the current idle status, what 
value is the idle status from some duration in the past?

> indication that something really extends <tuple> not <status>.

Why? If status and timed-status are "peers", then if something is valid 
in timed-status, it should also be useful in status, as a general rule, no?

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Mar 2004 14:06:21 -0500

inline.

That seems fine.

OK.

Yes, that makes sense.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 13 Mar 2004 21:21:35 -0500

> in timed-status, it should also be useful in status, as a general rule, no?

I meant the converse: if something doesn't make sense having a time 
period associated with it (e.g., relationship), it should probably be in 
<tuple>, not <status>. <idle> seems doubtful, as you pointed out.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 13 Mar 2004 21:21:35 -0500