Minutes from Calendaring Summit, 7/24/96

["John W. Noerenberg" <jwn2@xxxxxxxxxxxx>]

The minutes, at last.

[Editor's note:  I've used some text/enriched constructs to set off portions of the text, and make the sections more clear.  I hope you will find this helpful.  I also used some white space to set things off, in case the rich text is swallowed.  If anyone has trouble with the message, please let me know and I'll send a text/plain version.  Actually, the only things I used were <bold>, </bold>, <italic> and </italic>. -- jwn2]

The Day Begins

Mark Szelenyi of Netscape began by explaining why he was opening the meeting instead of Erik Hahn.  Erik's new baby boy was born late Tuesday night!  As a result, Erik was otherwise occupied.  Mark thanked Nancy Sullivan for handling the logistics for the meeting, and the attendees joined in applauding Nancy.  Mark then turned the meeting over to Anik Ganguly of On Time.

Anik's intro

Anik Ganguly began by acknowledging the flap in the mailing list over the press releases.  He asked that we put that behind us on concentrate on the task before us: organzing ourselves to work effectively for protocols that enable calendar and scheduling programs to interoperate for the benefit of their users.  He proceeded to present the agenda for the rest of the day.  He then introduced the first speaker.


Ron Rassner's presentation (Mike Roszkowski, CNI)

Mike Roszkowski of CNI, using notes from an article by Ron Rassner, talked about the impact the use of group and personal scheduling software can have on an organization.  He pointed out the lack of standards limits the use of time management tools, but the existence of standards will promote interoperability, hence increasing the utility of time management tools for individuals and organizations.

He observed the success of Internet email is the result of the wide acceptance and implementation of the protocols that underly email on the net.  He continued that time management software needs the same kind of standards to achieve similar success.  Mike recited the different effort that have been made to find a standard, and lamented their lack of success.  He concluded with a plea to cooperate and collaborate for the good of our customers and our mutual benefit.

Anik took the floor to introduce a number of representatives from companies that wished to make brief statements about the meeting today.


Nina McIntyre (Lotus)

Nina McIntyre of Lotus observed that today the number of email users and users of PIMS and group calender tools was roughly equal.  Over the next couple of years the market for calendar tools is expected to grow to 4 times its present size.  Because people use calendar management tools in different ways that may require more than one standard evolve for interoperability.  She concluded by saying that Lotus was attending today because they want to focus on the technical work of building standards for interoperability.


Ian Ferrel (Microsoft)

Ian Ferrel of Microsoft stated briefly they were here because they want to participate in the technical work of this group.


Mark Szelenyi (Netscape)

Mark oberverd that Netscape is a company built on Internet standards.  Netscape is interested in entering the market for calendar management software, too.  The importance of standards to Netscape, and their interest in this market led to their offer to have the meeting.


Jari Mäenpää (Nokia)

Jari Mäenpää of Nokia held up Nokia's new cellphone/Internet terminal.  It is a handheld device intended not only to be a personal communicator, but a personal tool to help manage information, appointments, and other aspects of an individual's life.  Because of the constraint of being a handheld device, it possesses only limited memory.  Standardizing protocols greatly helps efficiently using the resources of a device like the new Nokia Internet communicator.  Besides the wireless protocols for cellular phones, there are other media that are useful for communication such as infrared, 2-way paging, etc that are not curently being considered as transports by the IETF.  Jari asked that other media be considered when developing standard communication protocols.  Anik endorsed the idea that it is important to think of being able to work in the small space of phone operating system.

Anik then introduced Keith Moore, one of the IESG Applications Area Directors, to talk about the Tao of the IETF.  Anik reminded everyone that one of the goals of this meeting was to seek consensus to bring about standard calendar management protocols thru the IETF.


Tao of IETF (Keith Moore IESG rep)

Keith began by talking about the documents that describe how the IETF works.  He referred to RFC 1718, The Tao of the IETF, as basic to understanding the process.  In addition, RFC 1602 describes the how a standard evolves.  The POISED working group (WG) is currently revising 1602.  There is a set of documents, draft-ietf-poised.* that describe the methods of the IETF.  To learn more about the workings of the IETF, Keith encouraged people to explore <http://www.ietf.org>.  Because most of the attendees are unfamiliar with IETF processes, Keith proceeded to summarize the process.

The IETF works in WG.  A working group has a narrow focus with a limited lifetime.  There is no formal membership process.  Anyone can join a working group.  You join by being interested in the problem and participating in finding its solution.  Individuals join by coming to IETF meetings, and by joining the mailing lists where the majority of the discussion about a problem takes place.  Individuals are members, not companies.  Everyone has a right to be heard in the IETF.  No voice speaks louder, simply because they come from a large organization.  Decisions in WG are made by rough consensus, and with working code.  At this point several IETF regulars shamelessly demonstrated "rough" with interruptions to clarify important points they thought Keith omitted.

Keith continued the IETF holds meetings 3 times a year.  However, most work is done on the mailing lists which are part of each WG.  At each meeting each working group meets for the "face time" that is necessary to work out the thorny issues that can't be settled on the mailing list.  In addition, a WG may hold meeting outside of the IETF regular meetings, if it deems them necessary.  Decisions of the WG can only be reached, however, on the mailing list to afford all participants the opportunity to contribute to the consensus of the group.

IETF drafts are the ONLY route to an IETF standard, a standard RFC.  RFC drafts are posted to the RFC editor who maintains them in an archive maintained by the IETF Secretariat.  The archive is located at ds.internic.net.  Once a draft has been posted, an announcement is made to the ietf mailing list of its existence.  RFC documents have a standard outline, but the structure is minimal.  Every draft expires 6 months from its submission date.  At its expiration an RFC will either advance to the next stage in the standardization process, be renewed for further work, or be retired.  A draft can be the product of individual work or a collaboration.  Drafts may be submitted either under the auspices of a WG or individually.  Generally WGs take responsibility for drafts intended for standards track.  Once a WG accepts responsibility for a document, its fate requires the consensus of the WG, and the WG, and by extension the IETF, is solely responsible for changes to the document.  Keeping change control is important for maintaining the integrity of IETF documents.  It is not possible for there to be two "authoritative" versions of an RFC.  RFCs may reference specifications of other organizations, but it may only reference other RFCs which are advanced at least as far towards STD as it itself has advanced.

The WG chair is the sole arbiter of when consensus has been reached.  Consensus is not a simple majority of the WG, but neither is unanimity required.  Once consensus is reached, the WG submits the document to the Area Director(s) (AD) for consideration by the steering committee, the Internet Engineering Steering Committee (IESG).  Once the IESG accepts the document it is submitted to the IETF mailing list for Last Call to allow the general readership of the IETF a last opportunity to comment on the document before it advances to the next stage.  Last Calls are for a defined period.  Once the period elapses and the IESG concludes no serious questions were raised about the document's validity, it advances to the next level.

The WG chair is free to use any method which successfully establishes consensus in the group.  If members of a WG disagree with the methods employed, they can appeal to the Area Director to intervene.  Generally, the AD will confer with the rest of the IESG to help resolve the dispute.  If this fails, the members of the WG can appeal to the Internet Architecture Board to adjudicate the issue.

A standards track document evolves through 3 stages, Proposed Standard, Draft Standard, and Standard.  A Proposed Standard is a description of a protocol which the authors (or editors and collaborators) believe addresses the problem the WG group was organized to solve.  An RFC advances to Dreft Standard when 2 independent, interoperable implementations of the protocol have been completed, and the WG has reached consensus the protocol is sufficiently mature and robust that is likely to find wide acceptance.  An RFC advances to Standard, when there is significant implementation, successful use and broad acceptance of the protocol's utility to the Internet as a whole.

Not all RFCs are standards track documents.  There are RFCs which are designated as historic, informational, experimental, and Best Current Practice.  The IETF also has a rich tradition of April 1st RFCs, which most people don't take seriously.  Keith provided a short defintion of each of these other varieties of RFC.  He noted that BCP RFCs are somewhat controversial within the community.  They tend to be policy statements, with no formal interoperability requirement, and as such, my inhiibit the development of sound technical practice -- at least, that is part of the argument.

Keith reviewed the IETF organization.  In addition to IETF members, which is a highly informal body (this is why it makes no sense to speak of someone "close to the IETF"), there are some specific groups that guide the work of the IETF.  Already mentioned is the IESG which consists of the Area Directors, the IETF chairman, who also chairs the IESG, and the RFC editor.  The Internet Architecture Board, IAB, is a technical advisory board.  The members role is to provide technical oversight for the IETF, as well as function as the court of last resort to adjudicate technical disputes.  IANA,  Internet Assigned Number Authority, is responsible making sure that protocol parameters are uniquely assigned to prevent conflicting use.  The IRTF, Internet Research Task Force is a research body which performs deeper investigation into issues that cannot be quickly resolved by the IAB.  They make recommendations to the IAB.  The Secretariat, which includes the RFC Editor, is responsible for maintaining IETF archives, the ftp server, web pages, and the like.  The Internet Society (ISOC) is a chartered society responsible for approving the nominations to the IAB.

At this point, Keith summarized where this group is in the process of forming an IETF working group.  Working Groups require a charter, approved by the IESG, which outlines the scope of the working group (its focus), and the work it plans to accomplish.  WGs also need mailing lists and archives.  The charter should be written as narrowly as possible to insure that work is done in a timely way.  WG that last more than a year generally are not productive.  Today, this group lacks a charter, and the mailing lists and archives haven't been successfully established.  The approval of the charter will take at a minimum a couple of weeks.  The other things can be done more quickly.

Someone from the floor asked how we could avoid the fate of the SNMPv2 working group.  Keith felt that it broke down primarily because those responsible for the architecture of the protocol were unwilling or unable to recognize the difficulties the architecture posed for some class of devices for whom the protocol was supposed to work.  He suspects that fate can be avoided in this group, because all the technical proposals he's reviewed show a great deal of commonality already.  That suggests differences can be resolved without much rancor.

Dave Crocker volunteered the resources of the IMC to provide the mailiing list home and document archive.  The archive address will most likely be <http://www.imc.org/calendar>.  Dave mentioned that Keith had written a very useful article about managing mailing lists.  A draft can be found at <http://www.cs.utk.edu/~moore/draft-moore-maillist-req-00.txt>


Marketing review (Heather Rose, Netmosphere)

After a short break, we resumed with Anik introducing Heather Rose of Netmosphere.  Heather had volunteered to conduct the Marketing analysis that we wished to perform during the meeting.  Heather proposed the following agenda for the discussion:
* Who are customers
* Requirements brainstorming
* Priorities

Who are the customers

We developed the list below of kinds of customers:
* Legacy, host-based users
This includes not only individuals, but proxies for other individuals, plus resources (conference rooms, etc) that are scheduled with these systems.

* Enterprise (dept vs IT vs individual)
Within an enterprise different requirements arise.  Different departments will choose different tools despite an enterprise wide mandate.
* Consumers
* Different access device
There are a multitude of special purpose devices that offer calendars.
* Mobile users
People who carry their environment with them, but periodically connect to the "home office".
* Heterogenous/location independent (nomadic)
People who wander in an enterprise and need access to their calendar information from a variety of portals.
* PDA access 
A special class of different access device
* Service provider -- one who publishes calendar data.  Several varieties of service providers were listed:
POP
Publishing
Business to customer
purchase mediation
Calendar information is provided in addition to other descriptive info
* IT integrates w/base system
* Calender/Schedule enabled applications
* PIM + email integration
* Person, place, thing - all these are entities that can be placed on a calendar
* Network protocol for agents
*  ToDo
discrete time interval vs. use of time

While developing the list, we discussed the differences between Calendaring and Scheduling (C&S).  Calendaring was described as the data placed on a calendar, and the manipulation of the information on the calendar.  Scheduling is negotiation between calendars to place informaiton on them.

As we were getting to the end of the list, we began to seque into brainstorming over marketing requirements for the interoperability.

Requirements brainstorming

* Interoperability of current and future
Backward compatibility with existing systems is important.  It has to facilitate data format exchange, the exchange of meeting notices, free/busy time searches, viewing calendars with differing levels of access, and different privileges for scheduling information on calendars.  It must also be possible to synchronize a calendar that only periodically connects to the network.

* Compatible with Internet transport
The protocols have to be able to work over the Internet.

* Should work with existing devicies such as PDAs, w/email, etc.

* Compatible with proprietary LAN protocols
Mustn't prohibt the ability to work over other transports beside TCP/IP.  In addition, there must be a way to work under an interactive model, and via store&forward methods.

We considered whether to match the customer classes identified with the requirements list, and decided to defer that to further discussion on the mailing list.

We attempted to categorize the classes of users into smaller sets.  This did not produce any definitive result.

We acknowledged that meeting access control requirements would be difficult to specify.

Recognizing the foregoing were questions about the priority of requirements, we realized we had sequed into discussing priorities.

Priority

We continued discussion of priorities by asking "What is the most important issue to address?".  The answer was to reduce the pain for users of using C&S tools.  It was observed there are 14-16 million PIM and C&S users today.  If we keep our goals simple, application developers can build on their existing work.

The requirements for interoperability we've listed were acknowledged as being difficult problems.

When muliple calendars exist for individuals, and responsibility for reconciling requests for time on particular calendars may be distributed across multiple calendars, finding the authoritative source of information about a calendar may become difficult.

Anik summarized the discussion about the marketing issues for C&S products by saying there must be interoperability between users relying on Internet transport.  Both interactive and store & forward models for data object exchange must be allowed for calendaring system users on a wide variety of devices.  Users must have control over access to the information, and that it is secure.  Finally, we must keep the protocols as simple as possible.

This was rewarded with applause, and we broke for lunch.

Tech Infrastrucure (Dave Crocker, Internet Mail Consortium)

The first part of the afternoon was a discussion led by Dave Crocker about the technical considerations that will influence the design of the protocols.  We began by listing a set of assumptions that were felt to be guiding principles.

* Reuse where possible
As much as possible we should strive to take advantage of existing work.  Our design should be chosen with an eye towards use beyond our specific problem domain.

* Variable throughput latency
We cannot rely on a consistent level of service always being available for transmission.  The procotols must have any built-in assumptions about the speed with with messages are delivered across the network.

* Internittent connectivity
Some classes of users of C&S protocols will have long periods of time where they have no live connection to the net.  Negotiation and exchange can only take place when a connection is live, obviously.  But utility of the data exchanged for the user must not end with the connection is broken.

* Transport services
There are a variety of transports offered by the Internet that we could use.  We listed a number of them:
TCP, UDP, Mail, Web, C&S-specific session layer.
Some commented that TCP would be a more appropriate basis than UDP for a session-layer C&S protocol, but no conclusion was reached by the group.  Besides transport protocols, we also listed other media besides traditional wired technologies that might be used for C&S transport.  These included cellular wireless protocols and Infrared.  There may be other possibilities.  One conclusion we reached is C&S protocols must be independent of the underlying transport.

* Importance of security model
Protecting the contents of a calendar store, and providing a means for authenticating access are necessary to meet the security requirements users will have for C&S products.  We debated whether C&S protocols would need to incorporate a security model or whether security models proposed for other uses on the net would be sufficient.  We weren't able to resolve this during the discussion, instead, concluding this will need to be taken up further down the path.

* Independence of data objects
We extended the idea of layer independence to further state that calendar data objects must be able to be represented independently of the transport protocols.  This is closely analogous to the email model, where message structure is separate from message transport.  This model has been very successful for email.  Many at the meeting felt this works well for C&S, too, although not all embrace this idea.

* Bits on the wire
Dave reminded everyone that what the IETF does, and what we're planning to do is describe the representation and transfer of calendar objects across the net.  We're not specify a representation model that must be used at the end points.  In fact, this is all we can do.  Going further is exceeding our goal of creating interoperability. Going further may unreasonably constrain choices for individual implementors.

* Architecture vs. implementation
This led into a lengthy discussion about architecture vs implemenation. It is our goal to design architecture, not specify the implementation individual organizations must follow.

We identitfed a list of concepts that will influence our architectural choices:
Data/Object
Transport
Agent/Role
Commands
Security
Management
Naming
Time reference

We spent some time examining what was meant by Agent/role. The system we choose will be made of entities that will perform specific functions.  The entities are the agents, collectively, the functions performed by each agent define its role.  There are a number of possible divisions of functions within a C&S system.  Each division defines a different set of agents and roles.  Dave proposed two divisions for us to consider:

1) User agent <-> Transfer agent model
2) Global service <-> client model

1) proposes the existence of "Calendar Islands" where calendar objects are stored and manipulated locally.  A "Common Calender" protocol would be used to exchange information between islands.  This model is analogous to the MUA <-> MTA <-> MTA
<-> MUA familiar in Internet email.  Transfer agents exchange objects with other transfer agents or a user agent.  A user agent exchanges information with an entity that consumes and generates calendar objects (for example, a person) and with a transfer agent.

2) proposes the existence of a global calender service with which client calendar agents would interact.  Exchanging objects between clients are facilitated by exchanges between the respective clients and the global service.

Distinctions between the models are subtle.  The may affect how the architecture scales for an arbitrarily large audience, for example.  Differences between the models will lead to differences in persistence of calendar objects.

We also spent a few minutes considering whether we should be including Directory Service in the issues that we should take up that affect C&S protocols.  While we agreed that Naming conventions are important, the task of retrieving information about particular named objects is being taken up by other groups and is best left to them.  We should be aware of their work to be sure any peculiarities of C&S are accounted for.

Dave concluded our discussion with a recitation of the list of important architectural concepts (given above).  He then turned the meeting back over to Anik.
When we resumed, Anik introduced speakers for each of the six proposals for C&S protocols that had been invited to present at the meeting.  Each speaker summarized the salient points of their protocols, it's advantages and disadvantages.  Some provided examples of the protocols' use.

VCalendar (Frank Dawson, Versit)

Frank provided an overview of the vCalendar protocol.  It is an for description for calendar objects.  He outlined Versit's goals for vCalendar's implementation, design principles, some of the technical fundamentals in its design, and Versit's current plans for evangelizing the specification.

Versit is principally interested in serving as an industry focus for interest in Personal Data Interchange (PDI).  To foster interest they are developing seed code for PDI applications.  The code available from Versit is unrestricted in use, and available for several platforms.  They are also researching applications for other media such as IR and smart cards.  In general, they want transport independence for PDI.

Frank listed a number of design principles they used to guide the specification's development so far: 
snapshot of personal calendar info
event, todo support
based on existing consensus
vendor neutral
transport independent
easy to implement
3-4 day proto implementation
quick demo

He described technical fundamentals on which the specification were built:
text-based
self-delimiting
abnf based syntax
ISO 8601 date/time
XAPIA, X/Open based calendar semantics
either event or todo entity
object applicable as clipboard drag/drop, body part, text file

and he showed some examples of objects constructed with the specification.

He anticipates Versit will make one more revision to the vCalendar specification before this fall, then hand the document over to the WG to further its progress towards a standard.

Calendaring & Scheduling Interoperability Protocol (Anik Ganguly & J. Scott Benson)

Scott Benson presented an overview of CSIP.  It's goal is to achieve interoperability between existing C&S applications.  The design assumed a store and forward transport model between systems, and no common name directory.

The model for interoperability assumes that a particular product establishes a "calendaring domain."  A protocol translation module between the domain CSIP would be responsible for transferring messages in and out of of the domain.  Between domains, CSIP would be used to exchange messages.

Scott walked us thru an example.

No assumptions about the message delay were made, and it is not required that receipt of a mesage be confirmed.

The protocol can be used for busy time searches, and for scheduling single events.  However, it is limited for scheduling recurrint events or to-do items.  No consideration was given for securing messages in transit, and the limits on access to the information in the calendar was not addressed.

There have been two implementations of CSIP, and the protocol has been revised at least once.

Internet Calendar Access Protocol (Pete O'Leary Clear Blue Network Systems, Inc.)

ICAP is an access protocol for Calendar objects based on IMAP.  It uses vCalendar as a data object definition, although vCalendar is not required as the object model.  Like IMAP, it is designed for interactive use with considerable collaboration between user agent and transfer agent.  ICAP enables retrieval of summary information, and it permits the existence of multiple stores for a particluar user.  In addition it is possible to browse the stores of other users, as well as simultaneously post to many stores.

Because it is an access protocol, it doesn't define the calendar object format, nor does it specify semantics for an event.  It doesn't address store & forward between transfer agents, nor does it deal with asynchronous access to the store.  Finally, ICAP assumes the existence of a directory service to find the names of objects.

One question raised that since ICAP is so close to IMAP, why not simply use IMAP?  Pete observed ICAP could be implemented as a set of capability extensions to IMAP.  However, requiring C&S vendors to supply an IMAP server might be confusing.  In addition, IMAP doesn't provide a satisfactory method for bounding a time interval which is needed for C&S data.  Another observation was this could be met by developing an ICAP profile that would drive an IMAP server.  The server would simply run on some other port than the standard IMAP port number.

Some other issues to be resolved for ICAP is there is no definition of the serach mechanism.  In addition, reliance on specifications for directory service and the calendar data object need to be resolved.

The protocol specification is available in the Internet drafts directory:
ftp://ds.internic.net/internet-drafts/draft-oleary-icap-00.txt

Scheduling Wide-area Transport Protocol (Bill Spencer, Phase2 Software)

Bill Spencer walked us thru a description fo SWTP.  Its design requirements are similar to other C&S protocols.  Bill described the format of messages exchanged in the protocol, the operations that are allowed and the assumptions about directory services and security.

For each session a client performs a bind operation, a series of optional operations on a target calendar, and an unbind to close the session.  In addition to operations to manage a particular users calendar, the protocol includes operations to add, modify and delete entities that can have calendars associated with them.  The protocol also defines a set of security levels that define levels of access to calendars.

The protocol is described by an internet draft:  ftp://ds.internic.net/internet-drafts/draft-spencer-swtp-00.txt.

There was some discussion about the limitiations of character sets that were required for the objects defined for the protocol, and whether it would be possible to define the character set to be used to represent the data in the calendar object.

Simple Scheduling Transport Protocol (Jay Hanna, On Technology)

Jay Hanna introduced SSTP saying their goals were much the same as others in terms of the capabilitiies of the protocol: data neutrality and communications between arbitrary end nodes.  In addition, they sought to keep the protocol as simple as possible for several reasons.  They wanted something easy for a diverse group to agree on, something whose design could be iterated quickly, and have low hurdles to adoption.

The protocol follows the models of other widely adopted protocols like SMTP, HTTP, MIME and vCalendar.  It assumes TCP for the transport, and this protocol must serve all possible devices.  The protocol can be characterized as one with a rich data model, and a small set of operations.

There are only 4 verbs defined in the protocol.  All data objexts have a type and an implied method for manipulation.  The objects are only defined for transfer, they don't imply a storage model.  It is assumed that some server owns the objects.  Jay listed the set of objects the protocol manipulates.  He provided a couple of examples of protocol exchanges.

Summarizing, Jay noted their goals were to provide product  interoperability, and allow for both client <-> server and client <-> interactions with the same protocol.

Application/Property (Darren Shakkib, Microsoft)

Darren Shakkib presented an object specification which is a MIME content-type, application/property.  Using application/property, it would be possbile to define a set of related objects specific for calendaring applications.  He defined the syntax for defining the attributes of a property and the range of values the attributes could take on.

Darrin offered that using MIME as basic model vehicle for defining the objects allows reuse of a generic parser, at the same time allowing a wide variety of object types.  Plus, it would be possible to use any transport that was capable of transporting MIME objects.  He proceeded to demonstrate how to create a profile using the syntax he proposed,  then defined 3 objects used in a calendaring application:  an appointment, appointment request, and a appointment response object.  He finished his presentation with protocol examples using the objects he defined.

Darrin was asked how his model handled the representation of recurring events.  It was pointed out that relying on the time format of rfc 822 could lead to problems with interpretation.

This concluded the presentation of technical proposals.  To aid analysis of the proposals and decisions of how best to proceed reducing the proposals to a single consistent set of protocols, Dave Crocker requested that each presenter provide the group with a summary of how their ideas differed from the others, and for other proposals for C&S protocols not covered at the meeting.

IETF Charter

Anik then took the floor to summarize what had been accomplished so far:
market requirements defined
group desires to follow IETF process
summarized the technical requirements for a protocol
we have overlapping proposals to sort out

In order to further the aims of the group, Anik wanted the group to consider the proposed IETF WG charter before it was submitted to the IESG.  The consensus was the charter was promising, but the scope of the work too ambitious.  We proceed to establish a set of six objectives for the WG, and establish some goals for completing them:

1. Charter
2. event and verb syntax
3. architecture/terms
4. Core objects
5. Object interaction
6. Integration

The charter will be amended based the discussion today and submitted to the IESG as soon as possible (within a week or two).  The WG deliverables are the definition of 4) Core objects specification, and 5) Object Interaction specification.  Completing the deliverables will require we resolve the architecuture and terms discussions.

Architecture includes the definition of a common language and approach for interaction for clients (and/or servers) in the C&S system.  We must also address questions about security and transport models.  These discussions should commence immediately.

We outlines a set of objects that should be included in the core set: name, datetime, event.  In addition we listed interactions between the objects that would have to be covered: event verbs, verb syntax, and a meta syntax used to describe the elements of the system.

Dave Crocker announced that the mailing lists to support the necessary discussion had been created at imc.org (while he was listening to the technical presentations), and that he would provide the facility to archive the discussions and documents this group creates.

Frank Dawson and Darren Shakkib agreed to form an design team to reconcile the differences between different object syntaxes that had been proposed.  They were confident they could work out the difference soon.

For target dates in the charter, we agreed that a 1st draft of the Core objects could be made ready by 1-Oct-1996, with resolution on the architecture by the same date.  A 2nd draft of the objects shoudl be ready by the San Jose IETF meeting (1-Dec-1996), and draft suitable for Proposed, along with a suitable draft for Object interaction would be ready for the Spring IETF meeting (15-Mar-1997).   Differences and last integration of the two drafts would be completed by 1-Jun-1997, with the specifications reaching Proposed status soon after the Summer IETF meeting next June.

With this agreement, Anik declared that we had reached our objectives for the meeting.  He thanked everyone for their participation, and we applauded our work for the day.

Respectfully submitted,


john noerenberg
jwn2@qualcomm.com
--------------------------------------------------------------------
Once the land touches you, the wind never blows so cold again.
You feel for the land like it was your child.  When that happens
to you, you can't be bought.
-- W. P. Kinsella, "Shoeless Joe", 1982
--------------------------------------------------------------------