Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/calsch/calsch-minutes-96dec.txt

Text File | 1997-02-04 | 12KB | 307 lines

Editor's note:  These minutes have not been edited.

Co-chair Anik Ganguly called the meeting to order at 1pm.  He announced
the agenda:

    * summarize 12/9 WG Chair - COS author 12/9 meeting

    * COS open issues

    * CIP open issues

    *  Moskowitz thoughts

    * Next Steps


He proceeded to describe the  meeting which took place the previous
evening between the WG chairs and the authors of the two Common Object
Spec (COS) documents that have been the topic of much recent debate.
As a result of the meeting, the authors agreed, pending consensus from
the WG, to use the vCalendar draft <draft-ietf-calsch-csct-00.txt>
as the basis for the COS.  Frank Dawson and Derek Stenerson will act as
document editors.


The WG is not required to maintain compatibility with the last Versit
version of vCalendar.  However, this is not license to make arbitrary
changes.  Any changes must be justified.  In general things which are
considered to be broken by the WG will be removed and/or replaced.


To facilitate understanding of the draft's status within the WG, a
document describing issues to be resolved will be maintained by the WG
chair.  Anik will take care of the list.  For issues for which no
consensus can be found, the chair will arbitrate the discussion between
the editors.  Bob Moskowitz will be the arbitrator.


To prevent confusion in the future about WG documents, only documents
posted to the WG by the chair will be authoritative.  In response to a
question from a WG member, AD Harald Alvestrand answered this way of
working would be acceptable.  He further reminded the WG the goal is to
produce the RFCs we've agreed to generate, according to our charter.


There was consensus by the WG this plan would be acceptable.  In
particular, the WG agreed <<draft-ietf-calsch-csct-00.txt> will be the
basis for the COS.

<The next
agenda item was to discuss current issues with the COS.  Frank Dawson
and Derek Stenerson proposed to summarize the list of resolved issues,
and then proceed to open issues.  It was observed that issues regarded
as resolved today may need reexamination in the light of implementation
experience gained in the future.


Two alternatives for scope and application of the COS were considered:
either restricted to use as an MIME subpart, or expected to be used in
other contexts.  The sense of the WG is that COS objects will appear in
several environments.  Representations that assume an email environment
will not be acceptable.


As Anik noted earlier, object property syntax will be derived from
<<draft-ietf-calsch-csct-00.txt>.


Properties will be unordered within an event object, excepting
sentinels.  This passed without comment initially.  However, later
discussion indicated grouping of properties may be desirable.


The applicable usage profile for an object could appear either as a
property or as a parameter to the MIME content type.  The preferred
approach is as a property.


Proposed property syntax permits datatype specification for the value
of the property.  Specifying the datatype will be optional.  It was
observed that if property values could have multiple datatypes,
optional inclusion could lead to problems with interoperability.
Implementation experience will provide valuable feedback.


In an effort to keep event objects compact, acronymic or abbreviated
property names will be adopted.  It is not anticipated that event
objects would be generally human-readable even without this rule, so
adopting it won't affect readability.


A means to extend the COS will be included.  The editors believed there
would be few restrictions on the nature of extensions.  In particular,
they were not concerned about a standard mechanism to extend the
protocol.  However, the WG did not accept that recommendation.  It will
continue on the open issues list.


The editors believed the WG was satisfied that time coordinates could
be expressed in local time with an offset to UTC.  This prompted a long
discussion proving this was not the case.  The issue of time
representation continues unresolved.  It was agreed that time
coordinates must be globally unambiguous.  Further there was strong
sentiment there be a single representation for time coordinates.  It
was observed this choice may make some time specifications in use by
some cultures impossible or at least very difficult.  Harald observed
that not only was there lack of consensus, there was lack of definition
of the terms under discussion prohibiting consensus.  More discussion
of this issue will occur on the mailing list.


Multi-valued properties will be allowed, according to the editors
understanding of the WG's consensus.  However, the syntax for
representing multiple values is still under debate.  It is not clear if
all values must share the same datatype, when multiple datatypes for a
property are allowed.  There will be more discussion on the list.


We then moved to issues known to be unresolved.


<draft-ietf-calsch-csct-00.txt> proposes an extensive set of
operations to insure functional completeness.  Some believe a smaller
set will be sufficient and promote faster adoption of the protocol.
This issue has not yet had much discussion.  Much more is needed.


Alternative methods for property normalization have been proposed.
Harald Alvestrand stated this must be reworked.  Keith Moore observed
this WG should not feel bound by choices made in other WGs, but that we
should use others work if applicable to our own. It was suggested that
only one method be chosen.


Ned Freed observed there were numerous syntactic issues that need to be
taken up, but would prefer to defer discussion to the mailing list.


MIME content types of application/calendar and text/calendar have been
proposed.  Those who believe the object content is not expected to be
easily human readable, advocate application/calendar.  Some believe a
readable form is both achievable and desirable and advocate
text/calendar.  The difference is that MUAs substitute app/octet-stream
and text/plain for subtypes they don't recognize.  Practical experience
is that app/octet-stream objects are less accessible to human receivers
than text/plain, hence the out-of-band opportunity to interpret the
object seems smaller with app/calendar than text/calendar.  Resolution
of this point will require better understanding of object syntax.


Whether to allow the content of addressee headers to be interpreted as
meeting attendees in event objects remains unresolved.  Little time was
left for debate during the meeting.


The other items on the open issue list were deferred to the mailing
list for discussion as time allotted for COS discussion had elapsed.

Calendaring Interoperability Protocol issues

Anik
reclaimed the microphone and announce we must move onto "The Protocol
Formerly Known as CIP".  He then turned the meeting over to Steve Hanna
and Peter O'Leary who are editing the document..


Steve and Pete recalled that originally 3 different drafts were
proposed.  One week before the meeting (just before the cutoff) they
succeeded in submitting a merged draft.  They also posted a open issues
document to the list.  (It was not resolved if Anik would maintain the
CIP list as he is doing for COS).


Steve and Pete began reviewing the open issues.


The protocol is based on TCP and the transport layer, rather than on
the presentation layer as is the case with email transport.  Reasons to
do this are to enable clients to provide more immediate response for
confirmation or errors.  This prompted a lengthy discussion where
advocates of email-as-the-only transport and advocates of
transport-layer transport enunciated their points of view.  It was
observed that existing applications for group calendaring generally
don't use email as a principal means for negotiating meeting
acceptance.  Chris Newman of CMU pointed out that when an immediate
response to a request is not possible, email-transport is perfectly
adequate.  Bob Moskowitz observed that diversity resulting from using
multiple transports limits the damage when a catastrophic failure takes
one transport off-line but leaves others available.


Alex Haupmann asked why a new transport layer protocol was needed at
all?  Why not use an existing one like HTTP?  Discussion followed where
advocates of this point of view argued this would simplify our task,
being able to rely on existing transport.  It also would avoid problems
with gaining its acceptance.  Advocates of an new protocol argued it
would be better tuned to the scheduling task.  If existing protocols
are not a perfect match, then limiting or adapting their use for
calendaring could be problematic.  In addition, it could impose
unacceptable burdens on the use of other transport protocols for their
original intent.


A concern was raised that a new transport protocol would demand an
additional, and as yet undefined address space for locating targets of
calendar messages.  This led to a further discussion of how to locate
Calendar Transport Protocol servers.  Adaptations of DNS MX records
were suggested, as well as using NAPTR records for this purpose.


More comment on the merged draft is needed, as well as resolution of
the debate over the necessity for a new protocol.

With that,
Anik turned the meeting over to Bob Moskowitz for a broader discussion
of transport issues regarding calendaring protocols.


Bob began by summarizing the arguments for and against a transport
protocol:

  a new protocol enables:

    * better change control

    * faster startup

    * avoids inter-wg negotiations

  but risks:

    * more revisions before achieving a satisfactory design

    * difficult penetration of the firewall

    * complex intra-wg negotiations over both transport and object
definition


  reuse of existing protocols enables:

    * use of shared code

    * use of others' experience

  but risks:

    * necessity to profile use of other protocol elements

    * requiring inter-wg negotiation to insure inclusion of necessary
features


Reusing an existing protocol may cause unintended side effects for the
original purpose of the existing protocol, as observed earlier.  Keith
Moore observed that if multiple wg adopt the "same" protocol, that may
cause parallel evolution of the protocol that may be undesirable.


Bob proceeded to outline some possible choices for existing protocols
that might be adaptable for transport.  Between servers he suggested
http and smxp.  SMXP has been proposed by workers at First Virtual
Holding.  Anik promised to publish a pointer to the protocol as it has
not been proposed as a stds-track RFC.  For client-server protocols, he
suggested imap, though others may be possible.


In order to reach closure, he suggested that unless agreement was made
on reusing existing protocols within N days, we should proceed with our
own definition.  A number of different points of view about this
recommendation were expressed. He deferred choosing a value of N to the
WG, but suggested it should be less than 30. Keith Moore asked if
someone would be interested defining an applicable subset of http.


Dave Crocker raised the point there has been little discussion to date
about security concerns for these protocols.  He suggested we not go
out of our way to develop specific protocols for this purpose within
either transport or object definitions.  Instead, this would be a area
we could profit from work by other WGs.  We should make the effort to
specify what is required to adequately secure information exchange by
calendaring protocols.

To close
the meeting, Anik summarized the next steps that need to be taken.  The
open issues for COS will be posted to the mailing list. CIP needs to
justify its definiton of a new protocol, as well as take up other open
issues on the mailing list.  Specific proposals are needed on how
servers will be identified.  They should be proposed as Internet Drafts
and offered to the chairman to be submitted to WG and IETF editor.
There was no discussion of usage scenarios.  Some would like that to be
completed.  Anik suggested a survey of existing systems would be
needed.


Anik thanked the editors for leading their discussions, and the WG for
its participation.  With that he concluded the meeting at 3pm.<bold>



Respectfully submitted,




john noerenberg