I have written (and Pete has reviewed) a document listing the issues that have arisen concerning the Calendaring Interoperability Protocol (or perhaps I should say "the protocol formerly known as the CIP" :-). This document can serve as a starting point for discussion of CIP at tomorrow's meeting, since Pete and I have no formal "presentation." I have attached two copies of the document, one in Microsoft Word format (created with Word 6.0a on Windows 95) and one in ASCII format. Please forgive the poor formatting of the ASCII version. I haven't figured out how to get Word to translate nicely yet. Any tips? I created my SSTP draft using nroff. If you have comments on this document, please send them to the list (or to me, if you like). I will merge them into a revised version after the meeting and send it to this list, the imc.org site, and the I-D editor. Thanks, Steve Hanna ON Technology Corporation
IETF CALSCH Working Group Steve Hanna/ON Technology
Calendaring Interoperability Protocol Issues DocumentPete O'Leary/Clear
Blue Systems
<ietf-calsch-issues-cip-00.txt> December 9, 1996
Calendaring Interoperatibility Protocol - Issues Document
Abstract
This document is an IETF CALSCH working group document. The document
is used as a tool for recording issues and their resolution with
mailing list discussions.
This Issues Document is intended to track the resolution of issues
related to the `
`Calendaring Interoperability Protocol'
' deliverable.
The most current version of this document can be found on the IETF
CALSCH Working Group document archive at http://www.imc.org.
Issues within this document are classified as either being OPEN or
RESOLVED. Additionally, an issue may be found to no longer be a
concern and may be classified as WITHDRAWN. Issues falling into each
of these categories is listed in a separate section.
An issue is documented with a short summary title, a brief
description, and a list of identified alternatives. A resolved issue
will also include a description of the resolution and the date/venue
that the resolution was reached.
Distribution of this document is unlimited.
1. Open Issues
1.1 Need for Interoperability Protocol
Description: Do we really need to have a calendaring interoperability
protocol?
Alternatives:
1.
Create a calendaring interoperability protocol that works
over TCP.
2.
Create a calendaring interoperability protocol that works
over email.
3.
Extend an existing protocol such as HTTP to support
calendaring interoperability.
4.
Some combination of the above.
1
IETF CALSCHCalendaring Interoperability Protocol - Issues Document
December 5, 1996
1.2 Extensibility
Description: How can we provide for future extensions and allow some
servers or clients to implement only a subset of the
protocol?
Alternatives:
1.
Add a CAPABILITIES command that works somewhat like the
CAPABILITIES command in IMAP or the ESMTP EHLO command.
2.
Add a list of capabilities to the server greeting.
3.
Both of 1 and 2.
4.
Do nothing for now. Require the server greeting to include a
version number and add one of the above in version 1.1.
1.3 Protocol Name
Description: What should the calendaring interoperability protocol be
named?
Alternatives:
1.
Calendaring Interoperability Protocol (CIP, rather
antisocial)
2.
Scheduling and Calendaring Interoperability Protocol (SCIP)
3.
Calendaring and Scheduling Interoperability Protocol (CSIP,
already used by a predecessor, I believe)
4.
Internet Calendaring Interoperability Protocol (ICIP, not
very mellifluous)
5.
Calendaring Exchange Protocol (CEP)
6.
Time Exchange Protocol and IDentification (TEPID)
1.4 Architecture
Description: How should we describe the architecture that the
calendaring interoperability protocol fits into?
Alternatives:
1.
Use a section at the beginning of the protocol specification,
as we currently do. Perhaps expand on it a bit, adding
descriptions of how different kinds of scheduling systems
would use the protocol and how the interoperability protocol
relates to the calendaring access protocol.
2.
Split the architecture off into a separate document.
2
IETF CALSCHCalendaring Interoperability Protocol - Issues Document
December 5, 1996
3.
Don't worry about the architecture!
1.5 Authentication
Description: Should the authentication command use SASL?
Alternatives:
1.
Use SASL.
2.
Use a different scheme, perhaps a simpler one.
1.6 Result Codes
Description: What sort of result codes should the protocol use?
Alternatives:
1.
Numeric result codes.
2.
Mnemonic result codes.
3.
Full text error messages.
4.
Some combination of the above.
1.7 Character Set
Description: What character set should be used for the protocol?
Alternatives:
1.
US-ASCII
2.
ISO 8859-1
3.
UTF-8
4.
Make one character set the default and provide a way for the
client to select another one.
1.8 Language
Description: How can we support different languages well?
Alternatives:
1.
Don't put any text in the protocol that is intended to be
visible to the end-user. Put all such text in the COS.
2.
Make one language the default and provide a way for the
client to select another one.
3
IETF CALSCHCalendaring Interoperability Protocol - Issues Document
December 5, 1996
1.9 Server Identifier Resolution
Description: How should server identifiers be resolved to IP
addresses?
Alternatives:
1.
Use RFC 2052, backing off to host name resolution via DNS.
2.
Use straight host name resolution via DNS.
3.
Use another scheme.
1.10 Terminating Text
Description: How should we terminate or delimit objects sent by the
client with the SENDEVENT, RSVP, or FREEBUSY commands and by
the server in the response to the FREEBUSY command?
Alternatives:
1.
Use the period stuffing technique described in the current
spec.
2.
Use a byte count.
3.
Use MIME delimiters.
1.11 Counter-offer
Description: Should we add support for counter-offers? If so, how
should it work?
Alternatives:
1.
Don't support counter-offers, at least for now.
2.
Allow the RSVP command to include a counter-offer.
1.12 SELECT SERVER
Description: Since a single server can support more than one server
identifier, it would be cleaner to require the client to
specify which server they want before they can send any
commands.
Alternatives:
1.
Add a SELECT SERVER command.
2.
Leave it unclear which server identifier is being accessed.
3.
Require that all server identifiers on a given server be
accessed simultaneously.
4
IETF CALSCHCalendaring Interoperability Protocol - Issues Document
December 5, 1996
4.
Don't allow more than one server identifier to map to the
same server.
1.13 Multiple Event Ids for One Event
Description: Can one event have more than one event identifier?
Alternatives:
1.
Don't allow this. I don't know why it would be useful and it
would almost certainly cause problems.
2.
Allow this.
1.14 QUIT command
Description: Do we need a QUIT command?
Alternatives:
1.
No. Just have the client close the connection when they're
done.
2.
Yes. Suggest that the client send a QUIT command. Still allow
them to close the connection, if they need to.
1.15 Groups
Description: Should we allow one user identifier to stand for several
users? If so, how should we deal with RSVP for these users
and forwarding the event, if they are on other servers?
Alternatives:
1.
Don't allow one user identifier to stand for several users.
2.
Do allow one user identifier to stand for several users.
Don't allow RSVP from users hiding behind that user
identifier. Require servers to forward events using other
protocols.
3.
Do allow one user identifier to stand for several users.
Don't allow RSVP from users hiding behind that user
identifier. Provide support in the protocol for forwarding
events.
2. Resolved Issues
3. Withdrawn Issues
5
Attachment:
ietf-calsch-issues-cip-00.doc
Description: Binary data