More on merged drafts.

[Alec Dun <AlecDu@xxxxxxxxxxxxxxxxxxxxxx>]

The draft that was submitted was the best merge that could be done 
given the feedback from the group on the previous list of issues, and 
with the draft, a list of issues that still needed to be resolved was 
enumerated.  The draft was given a working group name because we were 
tasked with being editors of the draft at the last meeting.

We've spent a lot of time trying to work with you to merge the draft.  
You are a very busy person, and often it's difficult to get a hold of 
you or find a time that is convenient with you to meet.

There are some issues where using vCalendar constructs would not be 
consistent with the concensus of the group.  In these cases, Derik has 
used the rough concensus of the group rather than vCalendar content.  
Sorry.

In early November, there was a ~150 message e-mail thread discussing 
many issues including recurrance patterns, timezones, international 
calendar support, etc.  There was a rough concensus reached on many of 
these issues, and this concensus MUST be represented in the draft.  The 
draft needs to be iterated on continually to reflect discussions.

I'm not 100% sure how to make you happy about things where the 
concensus of the group contradicts what you want -- maybe there is no 
way.  Please don't stonewall progress because of this.  If you want to 
re-discuss issues, just say so and list the issues, maybe you have new 
arguments.  Don't submit an alternate draft without the discussed 
changes under the guise of "the other guy's draft is garbage".  That is 
not progress.  If you want to participate in the group by submitting 
drafts, at least do people the courtesy of incorporting the feedback 
from the list.

At the end of this message, I've included the latest list of issues 
(provided from Derik, who is trying to work with you).   These are what 
we should discuss at the December meeting to make sure we have adequate 
concensus on the remaining issues.  Please work with Derik to make a 
good, complete list of remaining issues so that the group can discuss 
and reach concensus on them.

Thanks,
Alec.
+1 (206) 936-4544


UNRESOLVED ISSUES (BETWEEN THE DRAFTS)
======================================

DATE, TIME, TIME ZONE FORMAT:
     Explanation: vCalendar uses ISO 8601 date/time format (maybe 
you've updated it to be compatible with rfc822/rfc1123?) .  Current 
draft (draft-ietf-calsch-sch-00.txt) uses RFC822/RFC1123 definitions 
for date, time and with some new ideas on specifying time zone 
information.  Needs to be discussed, reviewed, and understood.


DATA STREAM SENTINEL CHARACTERS
     Explanation: vCalendar uses BEGIN/END to delimit the 
objects/subobjects in the data stream. Current draft does not include 
any such sentinels.  Doesn't seem to have been an overwhelming response 
either way to this in the WG.


RECURRENCE MODEL
     Explanation: vCalendar uses the XAPIA and X/Open CSA recurrence 
and exception model.  The current draft (draft-ietf-calsch-sch-00.txt) 
uses a different model that is based on specifying one or more calendar 
restrictions (like a db query) using a predefined set of properties. 
Both have trade-offs that need to be discussed.


EXCEPTIONS TO RECURRENCE PATTERNS: 
     Explanation: The current draft specifies listing the dates of 
exceptions.  vCalendar allows for a recurrence pattern for exceptions 
for recurrence patterns.  Trade offs here too.


UNBOUNDED RECURRING MEETINGS 
     Explanation: The current draft does not allow recurring meetings 
to be unbounded (without end, or begin).  Some feedback suggests that 
we should be able to create unbounded meetings.


TIME ZONE RULES CHANGES AND RECURRING MEETINGS
     Explanation: If the time zone rules change, some suggest we need a 
(several) mechanism(s) for updating the recurring meeting with the new 
rules.


NON-GREGORIAN CALENDARS:
     Explanation: There is general consensus that we should not define 
a spec that disallows using alternative calendar types for scheduling 
purposes.  The current draft makes an attempt at defining a mechanism 
to allow this, needs to be reviewed.



RESOLVED ISSUES: 
================

PROPERTY NAME SYNTAX:  
     Explanation: original PROP-CAL syntax did not match MIME-DIR or 
vCalendar.
     Resolution: As Frank suggested, 
propname*[;paramname=paramvalue]:propvalue, same as syntax in MIME-DIR.

MULTI-VALUED PROPERTIES: 
     Explanation: Original PROP-CAL proposal only allowed single 
instances. vCalendar properties can have multiple instances (eg, 
ATTENDEE, NOTE, TEL,etc )and can be multivalued (ie, CATEGORIES, RDATE, 
EXDATE, etc).
     Resolution: Spec now based on MIME-DIR which allows multiple 
occurrences of a property. Properties may also have a single, or in 
some case, multiple values.

MIME CONTENT-TYPE
    Explanation: Original PROP-CAL spec based on new generic 
application/properties content type.  WG wants new type to be specific 
to calendaring, recommended MIME-DIR as a basis, suggestions included 
application/calendar.
    Resolution: New application/calendar media type is based on 
MIME-DIRs application/directory

HEADER TYPE VS CONTENT TYPE/HEADER AND CONTENT ORTHONOGONALITY
     Explanation: vCalendar specification does not currently provide a 
binding to MIME. PROP-CAL proposal makes use of the type parameters 
(e.g. Variant: One-Time)
     Resolution: Type parameters for profile, variant, were eliminated 
in current draft.  As Frank recommended, a "PROFILE" parameter on the 
CONTENT-TYPE header field is used (following MIME-DIR's lead) to 
indicate whether the data is an meeting request or response.  

DATA TYPING: 
     Explanation: vCalendar uses implicit data typing. Original 
PROP-CAL draft used an explicit data typing. 
     Resolution: As Frank suggested, introduced optional, VALUETYPE 
property parameter with a set of basic data types.  (added these types 
to MIME-DIR).

MINIMALIZATION OF PROPERTY NAMES.
     Explanation: vCalendar tried to make their property names as terse 
as possible. This was based on requirements from small chat and 
footprint applications such as paging and wireless.  Original PROP-CAL 
proposal had traditional RFC 822/1521 verbose descriptive names for the 
properties
     Resolution: WG consensus was when creating new names make them as 
short as reasonable and the new draft reflects this.  (Further 
recommendations on how to shorten them welcome).

EXTENSIBILITY
     Explanation: vCalendar uses the RFC 1521 "X-" non-standard tags 
for extensions. Original PROP-CAL did not specify how extensions are 
provided.
     Resolution: New draft allows for the non-standard "tags" for 
property names, property parameters, and enumerated values in the same 
way that MIME-DIR does.

ATTENDEE SPECIFICATION: 
     Explanation: Alec had raised the issue of using 822 headers for 
the recipient list to simplify things.  WG response was in favor of 
having a separate set of properties for this purpose like in vCalendar. 
 
     Resolution: The current draft addresses this by allowing separate 
properties to override 822 headers and allows for most if not all of 
the Attendee types defined in vCalendar to be specified.

ENHANCED MEETING REQUEST/RESPONSE EXAMPLES
     Explanation: PROP-CAL needed to have better examples of these.  
     Resolution: The current draft does.






> ----------
> From: 	owner-ietf-calendar@imc.org[SMTP:owner-ietf-calendar@imc.org] on 
> behalf of Frank Dawson[SMTP:fdawson@earthlink.net]
> Sent: 	Wednesday, December 04, 1996 8:12 AM
> To: 	'IETF Calendaring & Scheduling Mail List'
> Cc: 	'Anik Ganguly'; 'Cynthia Clark'
> Subject: 	Microsoft Document IS NOT A Merged Document
> 
> 
> Folks:
> 
> I have received a number of phone calls and email notes concerning Alec 
> Dun and Derik Stenerson's Microsoft document submitted to this mailing 
> list. In Alec's introductory note, he indicates that the document is a 
> "merged" document with the industry-supported, vCalendar contribution 
> that I was the editor for. Just to set the record straight; this is in 
> no way a merger of the two documents. If anything, this is solely a 
> Microsoft contribution.
> 
> As a matter of fact, many will probably find it odd that the document 
> was given a working group document name. Of course, this misnomer 
> allows the document to be indexed within the IETF website under our 
> working group. Thus incorrectly making some implication to novice 
> readers of a working group endorsement. This naming is unfortunate and 
> needs to be corrected by the IETF draft editor.
> 
> Certainly, one of the objectives within this mailing list and the IETF 
> Calendaring and Scheduling Working Group is the progression of a 
> working group draft for a core object specification and an 
> interoperability message profile. However, this is not contained in the 
> Microsoft document.
> 
> The Microsoft document is a subset of the functionality we currently 
> have in the draft-dawson-csct-01.txt and draft-dawson-csp-01.txt 
> document pairs. In addition, the contribution is not thoroughly thought 
> out and prepared.
> 
> I have no intention of beginning a non-fruitful round of message 
> flaming around this issue. I think that the Microsoft intent behind 
> this document may have been well minded. We need to resolve the 
> differences within our working group membership, not stoke any entropy 
> embers. So, publicly I would like to reinforce that I am open to 
> amending the MIME Calendaring and Scheduling Content Type and Content 
> Type Profile documents to address the broad consensus of the working 
> group. AGAIN, my point here is to address the misconception that this 
> document might invoke; that we have reached some broad technical 
> consensus represented by the Microsoft document.
> 
> The MIME Calendaring and Scheduling Content Type and Content Type 
> Profile documents that were submitted to this working group are found 
> on the IETF CALSCH Working Group document archive at 
> http://www.imc.org. If you have problems finding them, please contact 
> Paul Hoffman (phoffman@imc.org). In addition, the documents are 
> currently named as individual contributions to the IETF CALSCH at:
> 
> 	ftp://ds.internic.net/internet-drafts/draft-dawson-csct-01.txt and
> 	ftp://ds.internic.net/internet-drafts/draft.dawson.csp-01.txt
> 
> If you have problems finding them, please contact Cynthia Clark 
> (cclark@ietf.org). I did notice that the revision to the Calendaring 
> and Scheduling Content Type document was not correctly posted.
> 
> - - Frank Dawson
>