Re: To show Busy OR not to show Busy

suchet singh khalsa wrote:
> 
> 
> Hi All,
>      I have joined late in the game... So answers needed for some
> fundamental questions. Any help will be greatly appreciated.
> 
> (I have formatted my questions in HTML Table. Hope it does not get
> garbled...)

HTML is not a good thing to send to most (all?) ietf lists.

(1-2):
Busy time is determined by the attendee, not the iTIP object.
I could have the same entries in my calendar - and not plan
to attend. So I would not mark them as busy time.

(3):
[I am not sure which table your are referring to here and in
which draft. iTIP? CAP?]
I think this may help:
Your can CANCEL instances of an object. So they would exist
in the object when an instance or specific instances are
being canceled / acknowledges / ...

(4): 
No and No. There is no VCAR inheritance. Each calendar
is independent. The only exception being that they can not
violate any decreed VCARs.

Re: To show Busy OR not to show Busy

Re: To show Busy OR not to show Busy

Doug Royer wrote:

> Steve Mansour wrote:
> >
> > Here's my opinion:
> >
> > Sr. No. 1
> > 1. Mary should be shown as busy
> > 2. Tom should be shown as busy
> > 3. Mary should be shown as busy, Tom should be shown as free
> >
> > Sr. No. 2
> > 1. Mary should be shown as busy
> > 2. Tom should be shown as busy
>
> It's up to the CU/CUA to decide if they want there time
> marked as BUSY, not the protocol. Correct?

yep. that's why I indicated that it's my opinion.

My take is that when a person has been requested to show up at a
meeting, you should show their time as busy (that is, if you only have a
choice between 'free' or 'busy'; there's no option like 'pending'). As
an example, assume that I've been invited to a meeting Monday from
10:00a to 11:00a. If other people see me as busy at that time (even
though I've not actually accepted the meeting) they can invite me to
their meeting at some other time when I'm completely free. On the other
hand, if my time on Monday from 10:00 - 11:00 was marked as free, then
other people might invite me to a meeting from 10-11. I would only be
able to accept one of the invitations, and I would decline the others.
Similar double-bookings would be sure to happen with other attendees. I
believe that the overall amount of hassle and swirl associated with
getting the meeting scheduled will greatly increase if "needs action"
time is shown as free rather than busy.

iTIP provides capability to indicate whatever is appropriate, but not
the policy.

-Steve

Re: To show Busy OR not to show Busy

My opinions:

Sr.No. 1

  Q.No. 1) No, since Mary is not an ATTENDEE. The ORGANIZER is not
           by default expected to attend the meeting.

  Q.No. 2) No, since Tom hasn't accepted the meeting.

  Q.No. 3) Yes, since she is not an attendee, and not because 
           Tom declined.

Sr.No. 2

  Q.No. 1) If Mary is not an attendee, then no.

  Q.No. 2) No, since Tom hasn't accepted the meeting.

  Note: Tentative intervals in you agenda should have the value
        "BUSY-TENTATIVE".

Sr.No. 3

  Q.No 1 and 2)

    My guess is that an almost complete component might be useful 
    to allow a simple MUA/CUA to display information about the
    subject of reply/cancellation without accessing a database.

    For question 1) the RECURRENCE-ID should be used to identify 
    a single instance of a recurring event (not RRULE).

Sr.No. 4

  VAGENDA hierarchy and VCAR inheritance were removed from CAP.

  Q.No. 1) No.

  Q.No. 2) Yes.

--
Patrice

On Mon, 2002-06-03 at 18:38, suchet singh khalsa wrote:   
Hi All, 
     I have joined late in the game... So answers needed for some
fundamental questions. Any help will be greatly appreciated. 

(I have formatted my questions in HTML Table. Hope it does not get
garbled...) 

Sr. No.
Reference
Background for
the Question
Q. No.
Question
1.
iTIP /
FreeBusy
Mary has
REQUESTed a
vevent with
Tom as
attendee. The
REQUESTed
vevent has
STATUS set to
CONFIRMED. 
Another
Calendar User
Bill wants to
see FreeBusy
of Mary and
Tom for the
period of
Mary's
meeting.
1.
Should Mary be
shown to be
BUSY as she is
the ORGANIZER
and she is by
default
expected to
attend the
meeting?  
(Assume that
she has not
set role to
non-participant)

2.
Case 1:
PartStat for
Tom is still
NEEDS-ACTION: 
Should Tom be
shown to be
BUSY ?

3.
Case 2:
PartStat for
Tom is
DECLINED: 
Should Mary be
shown BUSY now
or since all
attendees have
declined to
attend, she
should be
shown FREE?

2.
iTIP /
FreeBusy
Mary has
REQUESTed a
vevent with
Tom as
attendee. The
REQUESTed
vevent has
STATUS set to
TENTATIVE. 
Another
Calendar User
Bill wants to
see FreeBusy
of Mary and
Tom for the
period of
Mary's
meeting.
1.
Should Mary be
shown to be
BUSY even
though she has
created the
vevent with
status
TENTATIVE ?

2.
If PartStat
for Tom is
NEEDS-ACTION
should he be
shown BUSY ?

3.
iTIP / REPLY,
CANCEL
Restriction
Table for
these methods
allows 0+
occurrences of
the following
properties: 
RRULE , RDATE,
EXRULE,
EXDATE, 
CONTACT,
ATTACH, 
RELATED-TO
1.
What
significance
do these
properties
have in the
MIME object
having these
methods ? 

Is it that the
RRULE received
in REPLY
method should
be interpreted
like this : 
if attendee is
ACCEPTing then
he means to
ACCEPT only
for those
instances
determined by
the RRULE in
the REPLY ?

2.
I cannot make
sense of an
ATTACH
property in a
MIME object
with method
REPLY or
CANCEL. 
Similarly for
the properties
CONTACT and
RELATED-TO.

4.
CAP / VCAR
There are 2
VCARs defined
with TARGET as
calendar id
"CAL-PARENT". 

There are 3
VCARs defined
with TARGET as
calendar id
"CAL-CHILD". 

The Calendar
"CAL-CHILD" is
contained in
the calendar
"CAL-PARENT" 

The word
"calendar" in
the above
three
statements
means
VAGENDA as
defined by
CAP.
1.
Whenever any
operation is
to be done on
the calendar
"CAL-CHILD"
should the
VCARs defined
on calendar
"CAL-PARENT"
also be
considered ?

2.
For e.g.: A
REQUEST is
received for a
vevent with
TARGET as
"CAL-CHILD".
This operation
does not
violate any
VCARs defined
on
"CAL-CHILD" but one of the VCARs defined on "CAL-PARENT" is violated.
Should this operation be allowed or not ?

Thanks in advance, 
Suchet Singh Khalsa 
Oracle Corporation 

Disclaimer : The statements and opinions expressed here are my own and
do not necessarily represent those of Oracle Corporation. 

draft-07 - XML

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.

Re: draft-07 - XML

Mark Davidson wrote:
> 
> What format are the replies in? Particuarly for the generate-uid and
> get-capability commands.

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:bernard <at> steltor.com
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

Re: draft-07 - XML

Mark Davidson wrote:
> 
> 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.

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
> get-capability commands.

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.

> 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.

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.

Re: draft-07 - XML

Doug Royer wrote:
> 
> Mark Davidson wrote:
> >
> > 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.

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

> > 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 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.

> > What format are the replies in? Particuarly for the generate-uid and
> > get-capability commands.
> 
> 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.

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
--

-- 
Bernard Desruisseaux                    mailto:bernard <at> steltor.com
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

Full proposal for current issue (i.e., Where to store METHOD info)

It has been more than two weeks since I gave answers to the
questions that, I believe, need to be addressed in order to
solve the current issue, and there is no other proposal that
obeys to RFC 2445 and RFC 2446, so I propose that the following
text be added to the current draft, and that all the examples
be changed accordingly.  I volunteer to do the editing!

Here are some hightlights of the proposal:

- Allow us to obey to RFC 2445 and RFC 2446 by making use
  of additional components (as was done in draft 05). This
  will avoid the hassle of changing the VERSION number;

- Make the model clear.  Commands are sent in VCOMMAND
  compoents, and results returned in VRESULT components.
  No more commands returned as a result to a command!

- The use of a VITIP component doesn't make query for iTIP
  objects a special case (no change required to CAP-QL);

- Querying on VERSION, PRODID, METHOD as well as X-PROP
  in iTIP objects will be possible, yet straightforward;

- The proposed model can easily be documented with ABNF
  (as in RFC 2445) and restriction tables (as in RFC 2446)
  (i.e., to assert whether a property is required, is optional
  and the number of times it may appear in a VCOMMAND component
  given the value of its CMD property).

I truly believe that my proposal will allow us to move forward
and to start addressing the other issues in the pipeline.

Cheers,
Bernard
-- 
Bernard Desruisseaux                    mailto:bernard <at> steltor.com
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

------------------------------------------------------------------------
X.1 Command Component

   Component Name: "VCOMMAND"

   Purpose: Provide a grouping of component properties that describe a
   CAP command.

   Format Definition: A "VCOMMAND" calendar component is defined by the
   following notation:

        commandc = "BEGIN" ":" "VCOMMAND" CRLF
                   commandprop
                   [ component ]      ; Defined in RFC 2445
                   "END" ":" "VCOMMAND" CRLF

        commandprop = *(

                    ; the following are REQUIRED,
                    ; and MUST NOT occur more than once

                    cmd / cmdid /

                    ; the following are OPTIONAL,
                    ; and MUST NOT occur more than once

                    latency /
                    destination /   ; Used with CMD:MOVE
                    uidcount /      ; Used with CMD:GENERATE-UID
                    identity /      ; Used with CMD:IDENTIFY

                    ; the following are OPTIONAL,
                    ; and MAY occur more than once

                    target / x-prop / iana-prop

                    )

   Description: A "VCOMMAND" calendar component is a grouping of
   component properties, and possibly including other calendar
   components, that represents a CAP command.

   Example: The following is an example of the "VCOMMAND" calendar
   component used to create a meeting in a calendar:

     BEGIN:VCOMMAND
     CMD:CREATE
     CMDID:abcd1234
     LATENCY;ACTION=ABORT:10
     TARGET:cap://cal.host.com/mary-relcalid
     BEGIN:VEVENT
     UID:20010919T103000Z-123401 <at> host.com
     ORGAGNIZER:cap://cal.host.com/mary-relcalid
     ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.host.com/mary-relcalid

ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.host.com/bob-relcalid
     DTSTART:20010920T180000Z
     DTEND:20010920T190000Z
     SUMMARY:Mary invites Bob
     END:VEVENT
     END:VCOMMAND

   The following is an example of the "VCOMMAND" calendar component used
   to search for a specific meeting in a calendar:

     BEGIN:VCOMMAND
     CMD:SEARCH
     CMDID:abcd1235
     TARGET:cap://cal.host.com/mary-relcalid
     BEGIN:VQUERY
     QUERY:SELECT * FROM VEVENT
      WHERE UID = '20010919T103000Z-123401 <at> host.com'
     END:VQUERY
     END:VCOMMAND

------------------------------------------------------------------------
X.2 Result Component

   Component Name: "VRESULT"

   Purpose: Provide a grouping of component properties that describe the
   result of a command.

   Format Definition: A "VRESULT" calendar component is defined by the
   following notation:

        resultc = "BEGIN" ":" "VRESULT" CRLF
                  resultprop
                  component          ; Defined in RFC 2445
                  "END" ":" "VRESULT" CRLF

        resultprop = *(

                   ; the following are REQUIRED,
                   ; and MUST NOT occur more than once

                   cmdid / request-status

                   ; the following are OPTIONAL,
                   ; and MAY occur more than once

                   target / x-prop / iana-prop

                   )

   Description: A "VRESULT" calendar component is a grouping of
   component properties, and possibly including other calendar
   components, that represents the result of a CAP command.  Multiple
   VRESULT components may be returned as a result of a single VCOMMAND
   (e.g., one VRESULT component for each TARGET property specified in
   the submitted VCOMMAND component).

   Example: The following is an example of the "VRESULT" calendar
   component return after a successful creation of a new VEVENT
   in a calendar:

     BEGIN:VRESULT
     CMDID:abcd1234
     REQUEST-STATUS:2.0
     TARGET:cap://cal.host.com/mary-relcalid
     BEGIN:VEVENT
     UID:20010919T103000Z-123401 <at> host.com
     END:VEVENT
     END:VRESULT

   The following is an example of the "VRESULT" calendar component 
   returned after a successful search command for a specific VEVENT:

     BEGIN:VRESULT
     CMDID:abcd1235
     REQUEST-STATUS:2.0
     TARGET:cap://cal.host.com/mary-relcalid
     BEGIN:VEVENT
     UID:20010919T103000Z-123401 <at> host.com
     ORGAGNIZER:cap://cal.host.com/mary-relcalid
     ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.host.com/mary-relcalid

ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.host.com/bob-relcalid
     DTSTART:20010920T180000Z
     DTEND:20010920T190000Z
     SUMMARY:Mary invites Bob
     END:VEVENT
     END:VRESULT

------------------------------------------------------------------------
X.3 iTIP Component

   Component Name: "VITIP"

   Purpose: Provide a grouping of component properties that describe an
   iTIP message.

   Format Definition: A "VITIP" calendar component is defined by the
   following notation:

        vitipc = "BEGIN" ":" "VITIP" CRLF
                 icalbody        ; Defined in RFC 2445
                 "END" ":" "VITIP" CRLF

   Description: A "VITIP" calendar component is a grouping of component
   properties, and possibly including other calendar components, that
   represents an iTIP message.

   Example: The following is an example of the "VITIP" calendar
   component return after a successful creation of a new VEVENT
   in a calendar:

     BEGIN:VITIP
     VERSION:2.0
     PRODID:-//ACME/DesktopCalendar//EN
     METHOD:REQUEST
     BEGIN:VEVENT
     UID:20010919T103000Z-123401 <at> host.com
     ORGAGNIZER:cap://cal.host.com/mary-relcalid
     ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.host.com/mary-relcalid

ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.host.com/bob-relcalid
     DTSTART:20010920T180000Z
     DTEND:20010920T190000Z
     SUMMARY:Mary invites Bob
     END:VEVENT
     END:VITIP

------------------------------------------------------------------------
X.4 Command Property

   Property Name: CMD

   Purpose: This property identifies the command in the VCOMMAND
   component.

   Value Type: TEXT

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

   Conformance: This property MUST be specified once in a "VCOMMAND"
   calendar component.

   Description: This property is used in the "VCOMMAND" calendar
   component to specify the command to be performed by the CUA or
   the CS.

   Format Definition: The property is defined by the following notation:

        cmd     = "CMD" cmdparam ":" cmdvalue CRLF

        cmdparam  = *( ";" xparam )

        cmdvalue = ( "GENERATE-UID" /
                     "GET-CAPABILITY" /
                     "IDENTIFY" /
                     "NOOP" /
                     "CREATE" /
                     "MOVE" /
                     "DELETE" /
                     "MODIFY" /
                     "SEARCH" /
                     "ABORT" /
                     "CONTINUE" /
                     x-name /
                     iana-token )

   Example: The following are examples of this property:

        CMD:CREATE

        CMD:MOVE

------------------------------------------------------------------------
X.5 Command Identifier Property

   Property Name: CMDID

   Purpose: This property specifies the identifier for a command
   calendar component.

   Value Type: TEXT

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

   Conformance: This property MUST be specified once in a "VCOMMAND"
   calendar component.

   Description: This property is used in the "VCOMMAND" calendar
   component to specify an identifier.

   Format Definition: The property is defined by the following notation:

        cmdid      = "CMDID" cmdidparam ":" text CRLF

        cmdidparam = *( ";" xparam )

   Example: The following is an example of this property:

        CMDID:abcd-123

------------------------------------------------------------------------
X.6 Command Latency Property

   Property Name: LATENCY

   Purpose: This property specifies the maximum latency time in seconds
   for a CAP command.

   Value Type: INTEGER

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

   Conformance: This property MAY be specified once in a "VCOMMAND"
   calendar component.

   Description: This property is used in the "VCOMMAND" calendar
   component to specify the maximum latency time in seconds for a
   CAP command.

   Format Definition: The property is defined by the following notation:

        latency      = "LATENCY" latencyparam ":" integer CRLF

        latencyparam = *(

                     ; the following is optional,
                     ; but MUST NOT occur more than once

                     ( ";" actionparam ) /

                     ; the following is optional,
                     ; and MAY occur more than once

                     ( ";" xparam )

                     )

   Example: The following are examples of this property:

        LATENCY:10

        LATENCY;ACTION=ASK:5

------------------------------------------------------------------------
X.7 Action Parameter

   Parameter Name: ACTION

   Purpose: To specify the action that should be taken when the maximum
   latency time is exceeded.

   Format Definition: The property parameter is defined by the following
   notation:

     actionparam  = "ACTION" "=" ( "ABORT" /
                                   "ASK" /
                                   x-name /
                                   iana-token )

   Description: This parameter can be specified on the "LATENCY"
   property.  The parameter specifies whether a command should
   be aborted when the maximum latency time is exceed or if the
   remote peer (e.g., CUA) should be prompted to find out if
   the command should be continued or aborted.

------------------------------------------------------------------------
X.8 Destination Property

   Property Name: DESTINATION

   Purpose: This property specifies the address of a calendar to
   which components should be moved.

   Value Type: CAL-ADDRESS

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

   Conformance: This property MAY be specified once in a "VCOMMAND"
   calendar component.

   Description: This property is used in the "VCOMMAND" calendar
   component to specify the address of a calendar to which components
   should be moved as a result of a MOVE command.

   Format Definition: The property is defined by the following notation:

        destination = "DESTINATION" destinationparam ":" integer CRLF

        destinationparam = *( ";" xparam )

   Example: The following is an example of this property:

        DESTINATION:cap://cal.host.com/mary-relcalid

------------------------------------------------------------------------
X.9 Unique Identifier Count Property

   Property Name: UIDCOUNT

   Purpose: This property specifies the number of UID properties
   requested as part of a GENERATE-UID command.

   Value Type: INTEGER

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

   Conformance: This property MAY be specified once in a "VCOMMAND"
   calendar component.

   Description: This property is used in the "VCOMMAND" calendar
   component to specify the number of UID properties that must be
   returned as a result of a GENERATE-UID command.

   Format Definition: The property is defined by the following notation:

        uidcount      = "UIDCOUNT" uidcountparam ":" integer CRLF

        uidcountparam = *( ";" xparam )

   Example: The following is an example of this property:

        UIDCOUNT:42

------------------------------------------------------------------------
X.10 Identity Property

   Property Name: IDENTITY

   Purpose: This property specifies a new identity for a CAP session.

   Value Type: UPN

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

   Conformance: This property MAY be specified once in a "VCOMMAND"
   calendar component.

   Description: This property is used in the "VCOMMAND" calendar
   component to specify a new identity for a CAP session.

   Format Definition: The property is defined by the following notation:

        identity     = "IDENTITY" identityparam ":" upn CRLF

        identityparam = *( ";" xparam )

   Example: The following are examples of this property:

        IDENTITY:bill <at> cal.example.com

        IDENTITY: <at> 

------------------------------------------------------------------------

Re: draft-07 - XML

> > 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".

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.