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

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 29 Feb 2004 07:03:13 -0500

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

> Implementors are advised to
>    ascertain whether the time values in the <future-status> elements are
>    plausible, for example, by checking whether the time stamp in a
>    notification protocol message corresponds to local time.

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.

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

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.

Thanks,
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: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Feb 2004 22:05:46 -0500

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

> than one (I think so)? In that case, can they represent overlapping 

That is an ugly case, because when there is an overlap, which takes 
precedence?

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Feb 2004 22:05:46 -0500

Paul