Subject: Re: To repeat or not...

From: [email-masked]
Date: Mon, 19 Jun 2000 15:02:09 -0400

John replied in part with:

>I think it depends on the context. 

I should have stated that up front; Im talking about iTIP, not CAP.

>If the error is in an
>incoming iTIP message, the receiver should send back an error to
>the sender, since they're the only person who can correct the
>mistake.

This sounds like a #4 which would be:

4: Flag the offender as bad; ignore the entire entity and return some 
automagic rejection response to the Organzier.

I had not listed this since originally we had designed REQUEST-STATUS to 
be used to convey this possible scenario back to the Organizer.  For 
example my CUA cannot grok RRULEs or EXRULEs so I can only accept 
repeating entries that do not contain them (or that also contain 
RDATEs/EXDATEs).  This was covered in 4.8.8.2 Request Status of RFC 2445:

     REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled
      as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2

Also, since in iTIP we do allow multiple REQUEST-STATUS values on some 
methods like REPLY and we also defined:

| 3.6          | Invalid rule.              | Rule value MAY be       |
|              |                            | specified.              |
...
| 3.13         | Unsupported component or   | Component or property   |
|              | property found             | name MAY be specified   |
(in 3.6 Status Replies of RFC 2446)

Another example can be found under 4.4.9 Error Reply To A Request as well.  So, we do have some prior art for instancing a subset of the 
repeating entry.  Im not for tossing it entirely since thats a bit heavy 
handed.  At least the DTSTART value is (or should be) always usable so why 
not use that.  That would allow the Organzier to do ADDs to add those 
repeating instances or possibly split them out individually...  Given we 
have a 2.8 I think that we should probably

Bruce
PS: We really really need to get the status codes organized a bit better.  For example, we 
have 2.8 for the I dont grok recurrence rules but we also have 3.13 which 
can also be ligitimately used for "I dont support RRULEs.".  Or, if I get 
a bogus RRULE then do I send back a 2.8 AND a 3.6??  I nominate Frank to 
do this minor cleanup... ;^b
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: John Stracke <[email-masked]>
Date: Mon, 19 Jun 2000 16:58:26 -0400

[email-masked] wrote:

> Im not for tossing it entirely since thats a bit heavy handed.
> At least the DTSTART value is (or should be) always usable so
> why not use that.

Mmm, not necessarily.  Suppose the EXRULE specifies that the
DTSTART is not included? (Dumb, but valid.)

One compromise would be to reply with the error message and give
the local user the event with no recurrences and a warning note
("There's a problem with the invitation; this is a recurring
event, but it's not clear when it recurs; the first occurrence is
probably happening, but I can't even be 100% sure of that; I've
already told the sender he's buggy.").

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Organ transplants are best left to the       |
[email-masked]|professionals.                               |
\==============================================================/