Minutes of the Working Group on Calendaring and Scheduling
Held at Munich (39th IETF), Aug 11, 12
WG Co-chair Anik Ganguly, called the meeting to order at=20
7:30 pm and reviewed the following agenda.
Calendaring and Scheduling Working Group Meeting
39th IETF
Munich, Germany
Monday, 11-August-1997
1930 - 2200 (7:30 - 10:00 pm)
Agenda
19:30 Agenda review
19:35 Discuss Model document
Title : Internet Calendar Model Specification
Author(s) : J. Noerenberg
Author(s) : J. Noerenberg
<ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-mod-01.txt>
20:20 Discuss iTIP part 1
Title : iCalendar Transport-Independent=
Interoperability=20
Protocol (iTIP) Part One: Scheduling Events and BusyTime
Author(s) : S. Silverberg, S. Mansour, F. Dawson, R. Hopson
Author(s) : S. Silverberg, S. Mansour, F. Dawson, R. Hopson
<ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-itip-part1-00.txt>
21:05 Discuss iCalendar
Title : Internet Calendaring and Scheduling Core Object=
=20
Specification (iCalendar)
Author(s) : F. Dawson, D. Stenerson
Author(s) : F. Dawson, D. Stenerson
<ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-ical-02.txt>
21:50 Review next steps
Setup Agenda for Tuesday meeting
22:00 Collect WG Roster, Adjourn
-----
Calendaring and Scheduling Working Group Meeting
39th IETF
Munich, Germany
Tuesday, 12-August-1997
10:15 =96 11:15 am
Agenda
10:15 Discuss iTIP part=20
11:15 Collect WG Roster, Adjourn
Model Document
--------------
The first item of business was discussion of the Model=20
Document. A number of editorial changes were identified=20
and accepted for the next revision. There was some=20
discussion of the use of the term =93minimal requirements=94 in=20
the model document and it was agreed that the term=20
=93minimal=94 would be removed.
The model document made reference to the exchange of=20
calendar properties using iTIP. Since iTIP does not really=20
allow property exchange, the model document will remove=20
this statement.
There was a suggestion to describe how to-dos can roll over=20
from day to day. This was rejected because the model=20
document should be as general as possible with respect to=20
the objects that can be exchanged between protocol elements=20
and since we did not envision adding to the model document=20
whenever a new object was added.
There was a discussion of the role of the owner and=20
organizer and it was decided that the model document would=20
describe these and in particular the policy regarding=20
ownership of entries in a calendar.
There was a great deal of discussion on the notion of an=20
authoritative store. The issues underlying this discussion=20
are: the existence of multiple copies of a user=92s calendar,=20
the access to them and the resolution of differences among=20
them.
Since the model document has two distinct purposes, it was=20
suggested that the document be separated into two. One=20
would be the abstract model itself and would say as little=20
as absolutely necessary in an effort to be descriptive but=20
not overly constraining. The second would describe by way=20
of numerous examples and scenarios how the calendar=20
specification might be applied. This would be an aid to=20
implementers who had not participated in the creation of=20
the specifications. This suggestion was rejected in favor=20
of keeping both =93sections=94 in one document, with=20
appropriate guidance to readers. The model document would=20
eventually become an informational RFC.
With that, the discussion of the model document was closed=20
and the iTIP editors were invited to discuss their=20
document.
ITIP (part 1)
-------------
The editors listed the recently resolved issues from the=20
ongoing discussion on the mailing list and identified a=20
collection of typographical and grammatical errors that=20
would be addressed in the next draft. =20
The issue of delegation was discussed and in particular=20
questions were raised about multiple people delegating the=20
same meeting to the same person, and about the method to=20
avoid looping. It was resolved that multiple delegations=20
will be accepted.
The iTIP editors restated the long-standing criticism about=20
the structure and semantics of the profile property and=20
offered a solution. The solution is to separate the=20
information contained in the profile into two attributes. =20
The name of the component/object would be specified=20
implicitly by the iCalendar object and a new property would=20
specify the method/verb (e.g. request, cancel etc.). The=20
MIME headers specified in iMIP would specify both the=20
component and the method explicitly as parameters on the=20
=93Content-type=94 header. This proposal was accepted.
On the subject of return codes it was stated that=20
experience has taught that 3digit return codes were=20
problematic because of the finite nature of the space they=20
could represent. The solution of dot-separated,=20
hierarchical return codes was offered and accepted.
There was discussion about generation of UIDs and Pete=20
Resnick suggested that the DRUMS WG had come up with a good=20
solution and that we should use the same solution. He took=20
the assignment to get the solution from DRUMS to the=20
editors of iTIP. Members of the audience noted that if the=20
solution was structured as local-part@hostname, the local-part=20
better not have meaning. They also noted that it was=20
essential to specify a maximum length for the UID.
The iTIP editors noted that they were still working on and=20
open to discussion on when to increment the sequence number=20
for an event and suggested that the issue be discussed on=20
the mailing list.
Finally, the iTIP editors discussed the plan for completing=20
the document. They wanted to finish the next revision of=20
the document in 6 weeks. A question was raised about the=20
relationship between the model document and the iTIP=20
document. The chair noted that, contrary to the charter,=20
it made sense to submit the two documents (and indeed=20
iCalendar also) at the same time to make sure that there=20
were no inconsistencies between the documents. The iTIP=20
editors noted that if both drafts were revised in the next=20
several weeks, the WG members at large could help ensure=20
that they were consistent. A question was raised about the=20
need to submit one or more bindings for iTIP with the=20
submission of iTIP to the IESG. A mail binding is in the=20
works and a second binding, to a real-time transport, would=20
demonstrate the transport independence of the iTIP=20
specification. This led to an inconclusive discussion of=20
the merits of HTTP as a real-time protocol for calendar=20
interoperability as time ran out.
iCalendar
---------
Next, the editors of the iCalendar specification discussed=20
the few open issues with that specification.
The issue of =93version=94 and =93profile-version=94 was discussed=20
and it was decided that Alex would submit to the mailing=20
list a proposal for a mechanism that would flag individual=20
properties with the =93Fail=94 parameter if a receiver that=20
does not comprehend the property encounters it. The=20
default behavior of the receiver would be to simply ignore=20
the property. This was accepted as a reasonable solution=20
to the problem.
The time-zone syntax was criticized a too wordy and it was=20
decided that a concrete alternative should be proposed on=20
the list by Harald Alvestrand as soon as possible and no=20
later than 4 weeks so this issue gets resolved.
There was an issue with multiple layers of encoding in the=20
specification and Chris Newman took an assignment to=20
specify the solution to this problem.=20
There was discussion again about the package of=20
specifications that should be submitted together and=20
someone raised the issue of the calendar access protocol. =20
It was decided that the model document would make a=20
reference to the access protocol and explain the=20
distinction between the interoperability and access=20
protocols but that, as agreed before and documented in the=20
charter, the work on the access protocol would continue=20
after the submission of the interoperability protocol. =20
Further, if the model document needed revision to support=20
the access protocol, a new RFC would be published to=20
obsolete the original.
iTIP (parts 2 & 3)=20
------------------
There was significant disagreement, even among the iTIP=20
editors, about the need to support to-dos and journal=20
entries at the same time as events. Some felt that the=20
specification would be incomplete without them and others=20
felt that the specification of to-dos and journals did not=20
have sufficient depth and the quality of that part of the=20
specification was suffering as a result. Also, the volume=20
of the specification was daunting.
After significant debate that appeared not be converging,=20
the chair suggested that the WG has accepted a time of=20
about 6 weeks for revisions of the iTIP documents. That=20
time should be allowed to enable anyone to surface=20
substantive issues that would prevent the editors from=20
coming to closure on to-dos and journals. And if none=20
arose, those components would remain in the specification.
The meeting adjourned for the night at 10:05pm and was=20
scheduled to continue at 10:15am the following morning.
12-Aug-1997 10:15am the meeting reconvened
There was some discussion to confirm the conclusions of the=20
previous night regarding iTIP. First, to-dos and journals=20
would be presented alongside events and the iTIP=20
specification would no longer have 3 distinct parts. A=20
unified presentation of the objects and the methods that=20
apply to them is the goal.
Security
--------
The chair made introductory remarks on the importance of=20
properly addressing security in the specifications that the=20
WG submitted to the IESG. The ADs underscored this point=20
but pointed out that there were no easy answers. At the=20
chair=92s request, the AD for Security, Jeff Schiller, had=20
asked Paul Hill and Bob Mahoney to work with the CalSch WG=20
to make sure that the protocols adequately addressed=20
security. =20
Bob and Paul led the discussion and identified the areas of=20
concern as authentication, encryption and authorization. =20
The current iTIP does not address the authorization issue=20
and the feeling was that it should because it was a=20
transport-independent issue.
The issue about the availability of an S/MIME specification=20
as a mechanism that the calendar protocol could refer to=20
was raised. It was stated that the only available,=20
referenceable mechanism was PGP/MIME.
A suggestion was made that the security model be described=20
in the model document and this was accepted by the editor=20
of the model document who invited contributions.
Bob and Paul accepted the assignment of posting a threat=20
model to the mailing list so that it could be discussed and=20
incorporated into the model document. Additionally, the=20
protocols themselves would specify the mechanisms they use=20
to mitigate the various threats. The editors of iTIP and=20
iMIP agreed to address security in their next revisions.
The Internet Draft that is supposed to provide protocol=20
writers guidance on writing the security considerations=20
section is available as draft-iab-secwks-sec-guidelines-
00.txt.
LDAP Schema
-----------
Alec Dun led a discussion of a proposal he had made for=20
using LDAP to locate a user=92s calendar and to store free-
busy information in the directory. He described the=20
proposal briefly, the associated draft is draft-dun-calsch-
schema-00.txt. He also noted that he was proposing that=20
the vCard schema be extended to include the calendar=20
related attributes.
Several issues were raised about the proposal, including:
1. How to associate multiple calendars with a user
2. The impact of putting free-busy time data inside a=20
directory
3. The calendar URL as specified in the proposal is very=20
mail centric and may not be appropriate for some systems
4. Security implications of the existence of this data in=20
the directory
5. Effect of LDAP caching on the calendar applications
6. The dependence of the implementations of the CalSch=20
protocols on LDAP
7. Lack of clarity on whether this is a mandatory or=20
optional mechanism
Based on these objections, and a general sentiment that we=20
needed a simple, non-LDAP dependent, solution to locate a=20
users calendar server, Alec took the assignment of=20
specifying the problem that the proposal attempted to solve=20
and get consensus on the list before we continued the=20
discussion of the details of the solution.
Closing
-------
The chair noted that the following work items were=20
committed at this meeting:
1. Model document 3rd revision with the results of the=20
discussions at this meeting
2. iCalendar document 4th revision with the results of the=20
discussions at this meeting and anything needed to support=20
iTIP
3. iTIP document 2nd revision with the 3 parts merged, new=20
format for presentation, security considerations and the=20
other results of the discussions at this meeting.
4. iMIP/iRIP binding documents =96 first drafts.
------------- The End --------------------------
Respectfully submitted,
Anik Ganguly
Note: These minutes were written by Anik Ganguly from the transcript
recorded by Alex Hopmann. The original transcript is available either from
Alex or Anik.