Subject: Re: RFC 2445 Proposal: ATTCOUNTER

From: "John Stracke" <[email-masked]>
Date: Wed, 27 Feb 2002 15:41:07 -0500

>  Conformance: This property MUST be specified in an iCalendar object
>  that specifies a counter proposal to a group scheduled calendar entity. 

Looks good.  However, that "MUST be specified" clause is a bit 
problematic, since then someone who implements to the updated RFC won't 
accept messages from existing implementations.

How about this:

An iCalendar object which does not have a METHOD:COUNTER property MUST NOT 
include an ATTCOUNTER property.  An implementation creating an iCalendar 
object which has a METHOD:COUNTER property MUST include an ATTCOUNTER 
property.  However, an implementation which receives an iCalendar object 
with a METHOD:COUNTER property and no ATTCOUNTER property SHOULD accept 
it, for compatibility with an earlier version of this specification.

/=========================================================\
|John Stracke                    |Principal Engineer      |
[email-masked]   |Incentive Systems, Inc. |
|http://www.incentivesystems.com |My opinions are my own. |
|=========================================================|
|NT's lack of reliability is only surpassed by its lack of|
|scalability. --John Kirch                                |
\=========================================================/

---

From: [email-masked]
Date: Wed, 27 Feb 2002 16:26:20 -0500

> it, for compatibility with an earlier version of this specification.

I had neglected to put in the backwards compatable text but the intent was 
there.  Thanks for reminding me.  (We could rev maxver to be 2.1 for this 
change so that a VERSION:2.0;2.0 would clearly be ruled out as a mandated 
case but thats more prose than I wanted to do but its an alternative none 
the less.)

I would wordsmith "iCalendar object" into "iCalendar group scheduled 
entry" because we use "object" to mean the entire VCALENDAR contained 
critter and it is legal to have multiple entities in 1 VCALENDAR that have 
different METHODs.  We agree on the intent; just need to make sure we dont 
use too broad a word brush...

Any other thoughts?

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: "John Stracke" <[email-masked]>
Date: Wed, 27 Feb 2002 17:41:21 -0500

>critter and it is legal to have multiple entities in 1 VCALENDAR that
>have different METHODs.

Mmm...but then the MUST/MUST NOT clauses apply to each (e.g.) VEVENT 
separately.  A component which has a METHOD:COUNTER property MUST have an 
ATTCOUNTER; a component which does not MUST NOT.  That way you don't have 
to get into, e.g., differences between events, timezones, etc.

Perhaps "component" rather than "object"?

/=============================================================\
|John Stracke                    |Principal Engineer          |
[email-masked]   |Incentive Systems, Inc.     |
|http://www.incentivesystems.com |My opinions are my own.     |
|=============================================================|
|Rope is rope, and string is string, and never the twine shall|
|meet.                                                        |
\=============================================================/

---

From: [email-masked]
Date: Thu, 28 Feb 2002 09:38:35 -0500

Graham asked on 02/27/2002 04:34:54 PM:
>     In what case(s) could ATTCOUNTER have 0 rather than 1 occurrence in 
the
> two COUNTER sections mentioned for RFC 2446?  Should it simply be 1?  :

Just as John noted in his changetext to the proposal, there are going to 
be older, existing clients that do NOT know about this new property so in 
order for them to work with 'newer' clients, the newer clients have to 
take this into account. 

We could make that:

      ATTCOUNTER     0 or 1     ; Older clients are unable to put this
                              ; property on so it is possible to receive
                              ; a COUNTER from them without this property
                              ; ALL newer clients MUST include this 
property
                              ; when COUNTERing.

but that just restates the text I forgot to put in originally that John 
noted.  (At least I remembered it for the restriction tables...)

Bruce

---

From: [email-masked]
Date: Thu, 28 Feb 2002 10:15:19 -0500

John wrote on 02/27/2002 05:41:21 PM:
> ATTCOUNTER; a component which does not MUST NOT.

The phrase "group scheduled calendar entity" was directly borrowed from 
RFC 2445 (Sections 4.8.4.1 Attendee and 4.8.4.3 Organizer) because thats 
how we previously drew a distinction on where the property should be 
allowed.  ATTCOUNTER has the same needs so I borrowed much of the phrasing 
to be consistant.

> Perhaps "component" rather than "object"?

Actually, because the METHOD is NOT on the VEVENT or VTODO but rather on 
the containing VCALENDAR I think that your suggestion would move the 
ATTCOUNTER out of the VEVENT/VTODO into the VCALENDAR and thats not where 
it should go.  I think it belongs inside them at the same level as 
ORGANIZER or ATTENDEE.  After all its possible to 'optimize' the iCalendar 
stream and have > 1 COUNTER from > 1 ATTENDEE to > 1 VEVENT/VTODO inside 1 
VCALENDAR and moving it out would negate this ability (and just require 
that > 1 VCALENDAR be sent instead).

Still I think we have basic agreement on the meat of the text.  Ill get 
some wordsmithing done on the "component" vs "group scheduled calendar 
entity" and repost the proposal unless there are other concerns.

Bruce

---

From: [email-masked]
Date: Thu, 28 Feb 2002 10:49:00 -0500

Doug asked on 02/27/2002 06:07:56 PM:
> (1) Per iTIP, COUNTER is not allowed in a VJOURNAL.
>     (So it could never have a ATTCOUNTER?)

Correct.  Its not scheduled between CUs so COUNTERing is not logical and 
as such ATTCOUNTER is not necessary.

> (2) Rather than saying ("VEVENT", "VTODO", "VJOURNAL"), how
> about saying:
> 
>    The property is specified within iTIP components that contain
>    the COUNTER property to specify the sender ...

I borrowed whole blocks of text from the existing RFC 2445 descriptions of 
ATTENDEE (and then added the restriction about the METHOD).  I would 
prefer that the text be consistant w/the published RFCs than have a new 
'tone' or wordsmithing.

Besides as already noted in response to John, the ATTCOUNTER belongs at 
the same level as ATTENDEE/ORGANIZER and not at the level where METHOD is 
(for opitmization reasons mostly).  We could put it at the METHOD level if 
we wanted to though...

Hmm, in rereading the iTIP restriction tables I see that for COUNTER we 
mandated that only 1 VEVENT/VTODO per VCALENDAR for those METHODs so we 
could have it at the same level as METHOD.  Id just have to add some prose 
to the proposal to clearly indicate that the counter is NOT for any 
components in the stream apart from the VEVENT/VTODO (or as the verbage 
goes "a group scheduled calendar entry").  Otherwise some folks may 
incorrectly assume that one could also COUNTER the VTIMEZONE definitions 
or some other TBD components instead of just the entry itself.

> (3) Lets let iTIP and any of its future rev's dictate where
>     ATTCOUNTER (COUNTER) goes in iTIP objects. In CAP lets just add
>     it to 'whatever iTIP allows for COUNTER properties' ?

Since I used much of the existing text from Section 4.8.4.1 Attendee Im 
guessing you want to rewrite the rules for ATTENDEE too??  What Ive 
proposed fits the requirements we discussed back in 2000 and does not make 
any radical new requirements that we do not already have in RFC 2445 so I 
think the basic text is sound.  As for iTIP, are you saying that the 
changes proposed are wrong/incorrect?  As for CAP, thats in progress and 
can include what it wants/needs.

> (4) Where you also proposing we allow COUNTER in 
> VJOURNAL?

Not sure where you got that from.  My original text regarding iTIP was:

The changes to RFC 2446 involve inserting a: 

     ATTCOUNTER     0 

into ALL restriction tables _except_ the ones in Sections 3.2.7 COUNTER (for VEVENT) and Section 3.4.7 COUNTER (for VTODO).  For those 2 cases it would be: 

     ATTCOUNTER     0 or 1 

so Im not sure where you got that I wanted to create a COUNTER for 
VJOURNALs...

Bruce

---

From: [email-masked]
Date: Thu, 28 Feb 2002 10:54:30 -0500

I originally wrote:
>   Description: The property is specified within the "VEVENT", "VTODO",
>   "VJOURNAL calendar components to specify the sender of a counter 

Strike any and all references to "VJOURNAL" in the proposal.  I missed 
that deletion.  Ugh, thats what I get for deleting my own text and 
restarting w/some copied text.  Sorry.

Bruce

---

From: [email-masked]
Date: Thu, 28 Feb 2002 15:12:40 -0500

Doug  wrote on 02/28/2002 02:47:10 PM:
> The marker would be in the ATTENDESS-CUA, how could the AA-CUA
> remove it? It can't be in the CS or two+ vendor implementations
> will not interoperate with respect to DECLINECOUNTER.

All this is moot as its all wishfull thinking as of now and it wont be in 
CAP and its not in any proposals on the table now.  We've digressed but so 
far I dont hear any arguments against the proposal (just some possible 
additions).  Is that a fair assessment?

Bruce