Subject: Session Scheduling

From: Denis BIGORGNE <[email-masked]>
Date: Fri, 14 Jun 1996 17:10:13 +0200

Henning Schulzrinne, and other before, put the question of the link
between conference invitation and agenda applications. Henning
noticed that it will be smart to update its own calendar automatically
after a conference scheduling. It seems to me that the main utility
of  such a link should be to facilitate the scheduling of meetings with
a limited number of participants, specially when the time-slots are few
and small, for instance for intercontinental conferences,  or for busy
peoples.

The current invitation protocol drafts are directed towards immediate
invitation made at the beginning or during the conference. A protocol
for conference scheduling will describe transactions which could be
done before a conference and may include a time-slot negociation
as well as a session ressources  negociation (and reservation ?). 
These transactions should be done between a conference initiator
application and the invitee agents (eventually through proxies). The
initiator application will have some links with name directory services
and, if some ressource reservation is needed, with the ressource agents.

The invitee agent will act as a network secretary, representing and
interfacing the user (invitee) with other networks agents or users for
the scheduling of meetings. Obviously this agent must be permanent,
running on a server reachable at any time. At a conference scheduling
request, the invitee agent may (depending on local rules):
	- try to locate the user (logged, pager, phone), notify him of the
invitation and interface him with the scheduling protocol for an immediate
negotiation reply.
	- mail the invitation to the user for a further reply.
	- stand for the user, accepting or refusing the invitation and 
negotiating the type of  the session (media, QoS) and the date of the
meeting using its own agenda.

This agent may have other functions like :
	- answer to personal inquiries (locating the user, sending 
business card a la Versit - http://www.versit.com, web home-page
URL,)
	- receiving mail and pre-processing it (acknowledgment)
The conference scheduling and invitation is not limited to MBone
session; it may be used for (internet) telephone call, for physical
meetings, for ISDN videoconference.

The agent will have two faces: a public one, obeying to common protocol,
for conference scheduling, immediate invitation, SMTP?, etc... , and
a private one like the interface with the user agenda (and indeed, I will
prefer to limit the disclosure of my agenda to my nearest workgroup).

First problem will be the relation with the session invitation protocol
drafts; could we envisage an extension, or should it be a different
protocol ?

Anyone interested ?

Amicalement,

	Denis

Denis Bigorgne
SEPT - Service d'Etudes communes de La Poste et de France Telecom
[email-masked]
phone: +33 31 75 92 29             fax: +33 31 75 06 31

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Jun 1996 14:56:34 +0200

A calendar application could, as payload, carry invitation messages
e.g. in SIP format.  (This is one of the beauties of a connectionless
protocol such as SIP.)  We have to make sure, though, that the
information in SIP invitations is sufficiently long-lived for this
(e.g., by removing IP addresses and replacing them with host names).

Note that I said "application" -- I'd like to keep the standardization
of calendar application interoperation protocol separate from the
conference control standardization.

Now, of course, a scheduling session is a slightly strange kind of
conference, so you might use SIP to establish a scheduling conference,
within which you transfer SIP invitations for the real conference.

Gruesse, Carsten

---

From: Denis BIGORGNE <[email-masked]>
Date: Fri, 14 Jun 1996 21:42:01 +0200

Carsten Bormann wrote :

> e.g. in SIP format.  
> ... (deleted)

I fully agree, and more, my description of the secretary (invitee) agent
was distinct from a calendar application. The secretary agent may
interact with the conference initiator under the conference invitation/
scheduling protocol - public - and, in another channel, may interact
with the user or its calendar application under proprietary or public
protocol (like Versit vCalendar). It is true that the functionnality of
the secretary could be integrated in a calendar application, but a
separate secretary may permit the use of existing calendar
applications and avoid the full publication of  calendar which is
needed in group scheduling applis (like Microsoft Schedule+).

> within which you transfer SIP invitations for the real conference.

A recurrence / bootstrap problem !  So my proposal was to run the 
transaction before any conference, in an asynchronous interaction
if the user isn't directly reachable.

Amicalement,

	Denis