Subject: draft-07 - XML

From: Mark Davidson <[email-masked]>
Date: Tue, 11 Jun 2002 16:41:50 +0100

I have read in the archives that XML has been removed since draft 07, 
but I am unsure about the new form of the commands.

Is CAP now sending text/calendar objects directly via BEEP?

If so, are there any extra properties for the commands?

What format are the replies in? Particuarly for the generate-uid and
get-capability commands.

Thanks,
  Mark Davidson

PS I have been reading this list for a couple of months getting up to 
speed. I am currently working on a calendar server.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 11 Jun 2002 13:28:06 -0400

> What format are the replies in? Particuarly for the generate-uid and

Hi Mark,

There is currently no consensus on the format of the
results for these commands.

My guess is that we'll have to create new components
to hold the results of these commands to avoid breaking
RFC 2445.

Cheers,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Tue, 11 Jun 2002 15:24:50 -0600

> but I am unsure about the new form of the commands.

We have not yet published all of those changes. They
will look like the 05 (I think) draft with CMD and
the other CAP commands inside the iCalendar objects.

> Is CAP now sending text/calendar objects directly via BEEP?

Yes. In fact I think that we will be able to just send
all (most?) iTIP objects down 'as is' (when you don't want
to do multiple parallel commands), and as they are self-defining,
the CS will know what to do with them - store them in the
unprocessed state.

BEEP knows what MIME is, so there is no need for another wrapper.
We will get send and get text/calendar MIME types.

All other (non-iTIP) iCalendar objects are unique to CAP
built on iCalendar. So there should be zero to minimum
impact on the other RFCs in most areas.

> If so, are there any extra properties for the commands?

Yes. The target has been moved back into the object.
And the command has been moved into the object. These
are optional for iTIP objects in CAP as iTIP objects
already contain that implied information in the METHOD property.

All CAP objects are pure iCalendar compliant objects.

The CMD property for example is not defined in RFC244[567],
however it can be easily added without impacting the
iCalendar "2.0" object format.

We will have to add 'or iana registered' to some of the places
they were lacking in 244[567], but there is no structure change
so the 'VERSION' property will still be "2.0".

> What format are the replies in? Particuarly for the generate-uid and

In iCalendar format.

Queries can come back in any iCalendar format depending on
the query. It is not possible to define every possible
contents for all queries.

Same with generate-uid and get-capability. They will be in the same
format as a query reply. No reason to invent a wrapper for each
reply type - the CUA knew what it asked for, it will need
to be able to know what it gets back. There will be new
properties and a reply container.

Nothing new that has not been discussed on this list. But
perhaps not exactly the way it was discussed on this list.

> speed. I am currently working on a calendar server.

Awesome!

I have been doing some edits and expect to check in the edits
so the other editors can see them by Monday of next week (apx Jun 17).
Then we hope to send out a draft as soon as they double check my work
for typos and errors (and as they also work it may not be a quick
turn arround). I also suspect they will make more tweaks before the
next push.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 12 Jun 2002 10:03:06 -0400

> the CS will know what to do with them - store them in the

iTIP objects will require at a minimum the addition of
a TARGET property, which is not allowed per RFC 2446.

> so the 'VERSION' property will still be "2.0".

What you are proposing here violates RFC 2445.
Here's how RFC 2445 defines the VERSION property:

4.7.4 Version

   Property Name: VERSION

   Purpose: This property specifies the identifier corresponding to the
   highest version number or the minimum and maximum range of the
   iCalendar specification that is required in order to interpret the
   iCalendar object.

   Value Type: TEXT

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property MUST be specified by an iCalendar object,
   but MUST only be specified once.

   Description: A value of "2.0" corresponds to this memo.

So, basically, VERSION:2.0 means that the iCalendar object is
fully compliant with RFC 2445, not that it is simply following
the format specified in RFC 2445.

It would seem that any change to the ABNF in RFC 2445 would
require a VERSION change.

> properties and a reply container.

If this is what you mean:

  BEGIN:VCALENDAR
  VERSION:2.0
  UID:uid1
  UID:uid2
  UID:uid3
  END:VCALENDAR

then you are violating RFC 2445, since an iCalendar object
MUST include at least one calendar component.  On the other
hand, the following construct would obey RFC 2445:

  BEGIN:VCALENDAR
  PRODID:-//ACME//DesktopCalendar//EN
  VERSION:2.0
  BEGIN:VUIDLIST
  UID:uid1
  UID:uid2
  UID:uid3
  END:VUIDLIST
  END:VCALENDAR

Cheers,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Wed, 12 Jun 2002 09:10:32 -0600

> > so the 'VERSION' property will still be "2.0".

After this I will ignore ALL of these three points.

	WE ARE ALLOWED TO CHANGE THINGS - AND IT IS IN OUR CHARTER.
	
	WE ARE ALLOWED TO ADD THINGS.

	VERSION 2.0 REFERS TO THE FORMAT, NOT THE CONTENT.

To anyone interested, look to the archives and you will see
that the chairs have issues statments with regard to
the above three facts. These are closed issues.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 12 Jun 2002 13:51:07 -0400

>         WE ARE ALLOWED TO CHANGE THINGS - AND IT IS IN OUR CHARTER.

Of course we are!  I never said otherwise.

>         WE ARE ALLOWED TO ADD THINGS.

Of course we are!  I never said otherwise.

>         VERSION 2.0 REFERS TO THE FORMAT, NOT THE CONTENT.

Correct, and here's what RFC 2445 says (Section 2):

   This memo makes use of both a descriptive prose and a more formal
   notation for defining the calendaring and scheduling format.

   The notation used in this memo is the ABNF notation of [RFC 2234].
   Readers intending on implementing this format defined in this memo
   should be familiar with this notation in order to properly interpret
   the specifications of this memo.

It is my understanding that RFC 2445 makes use of ABNF "for
defining the calendaring and scheduling format" and that you want
to change the ABNF, which in turn will change... the format!

Cheers,
Bernard