Freetime Lookup -Reply

[Steve Carter <srcarter@xxxxxxxxxx>]

Thank you for your thoughts on this matter. My comments are below:

-src
Steve Carter
Novell
srcarter@novell.com

>>> Denis BIGORGNE <Denis.Bigorgne@sept.fr> 08/30/96 11:06am >>>
>In the C&S Overview document, the Freetime Lookup function  
>seems adapted to corporate environments, where calendar 
>sharing is a fair rule. Im not sure that extensive request of 21 
>days freetime map could be accepted for automated 
>appointment scheduling made outside the enterprise ; there 
>could be too many indiscretions opportunities, like trying to 
>know who is busy at the same time...

Point well taken, but I think we will find ourselves needed to organize
groups of disperse individuals for meetings (phone, teleconference,
face-to-face, chat, collaborative document, etc., etc.) much more in the
future and the need to schedule time from a free time list is very
important. Each of us has time that is private, time that is scheduled, and
time that is available. I suggest that we have this kind of designation for
our calendars. If several people have time marked "private" at the same
time and others can see it, that may or may not be bad.

Thus to my next point. We need to have a globally deployed PKI that will
allow us to use certificates at various levels to authenticate requests for
calendar (read personal and/or professional here) information. Even at
this point you still have a valid point about the "private" time or
"scheduled" times that you don't want others to interrogate. <<on-line
thought>> Perhaps we need another calendar distinction called "black
out" that returns a random mixture of non-response, scheduled time,
and/or private time? <<end of on-line thought>>

>Instead of a one-shot ORing of freetime maps, the appointment 
>scheduling could use a multi-round negotiation algorithm 
>controlling the exchange of a list of time-slots (or ranges) 
>arranged by preference order. At each step, the list should be 
>narrowed, discarding the impossibilities ; if the list is reduced 
>to null, an extension should be proposed... For two-parts 
>meeting, a simple round may be sufficient ; for numerous 
>invitee, many rounds could be required, with a succession of 
>narrowing and extension phases. At SEPT, we developed a PC 
>conference appointment scheduling demo using list of ten time-
>slots ; I have been told that in some corporation, the directive 
>for non-automated scheduling requires an initial list of  only 
>three time-slots.

In my response to Peter's paper I specified that ORing takes place as
each response is received and that work to schedule a meeting can be
taking place during the receipt of the free time lists. On the client each
free list is processed as it is received. Perhaps you are talking about
having a server process do the progressive ORing? I'm not clear what
your point is here -- please clarify.

>Another item seems problematic to me : the resource 
>caracterisation. In Petes document, a resource is simply 
>another agenda which must be inquired. This is certainly true 
>for common ones, like network reservation. But  :

>- some resources are private : if you are trying to schedule a 
>videoconference, the networks resources are (more or less) 
>common, but the terminal equipments are private and 
>external requesters are probably not allowed to make 
>reservations - it is a task to be done by each invitee calendar 
>agent (or user himself).

Thus, again we see the need for certificate processing. We need to be
able to authenticate a scheduler. Private resources must authenticate the
scheduling person (or agent) before allowing any access to the free list
and before accepting any schedule. This is even more important to
prevent "denial of service" attacks. I can imagine some unsavory
characters shutting down a set of resources by scheduling bogus
meetings and consuming the time slots.

>- the disponibilities of the resources are dependant of the 
>time. By instance, an user may be present at some location 
>at some time, and can only be call by phone at another time.
>A solution could be that the items of the negotiation list (or of 
>the freetime map) should not be simple time-slots but consist in  
>a time-slot plus acceptable media (physical location, phone, 
>videoconferencing protocol,...). Note that the  
>videoconferencing descrition is not trivial - see IETF mmusic 
>WG.

I agree here as well. Time zone handling must be done in the context of
the location of the person (resource) at the time of the scheduled event.
The fact that the event is accepted in one time zone does not preclude
the fact that movement will occur and the event will be participated in
from another time zone. I have suggested that the person scheduling be
advised of the time zone context that the accepting party has designated
for their attendance at the event. I will look into the minutes and other
information from the ietf mmusic WG.

>I understand my comments goes beyond the capabilities of the 
>majority of the current calendar products ; this is explainable - I 
>dont speak from a technology provider point of view, but from 
>an user one, and more, an user interested in teleconferencing in 
>a general environment (not corporate). If we are to establish an 
>interoperability standard on the Internet, these aspects should 
>not be forgotten.

If we design to technology we'll get a technology solution. Design from
user work practice will yield a user solution. The latter will be used over
the former. We should constantly be putting on our "user" hat and/or
talking to users (doing a lot more listening than talking I might add). Thank
you for your response. The issues you have raised should be considered
as we move forward.
-src
Steve Carter
Novell
srcarter@novell.com

>Regards,
>	Denis

>Denis Bigorgne
>France Telecom / CNET / SEPT
>bigorgne@sept.fr
>phone : +33 31 75 92 29      fax : +33 31 75 06 31