Subject: [Ietf-calsify] Interpreting 2.1.5 Message Sequencing in rfc2446bis

From: John W Noerenberg II <[email-masked]>
Date: Fri, 18 Jan 2008 14:58:35 -0800

2.1.5 3. says:

"Attendees" send "REPLY" messages to the "Organizer".  For
replies where the "UID" property value is the same, the value of
the "SEQUENCE" property indicates the revision of the component
to which the "Attendee" is replying.  The reply with the highest
numeric value for the "SEQUENCE" property obsoletes all other
replies with lower values.

Should I take this to mean that the VEVENT in a REPLY only matches 
the VEVENT in the corresponding REQUEST if both the value of UID and 
SEQUENCE in each message match?  Or should it be that the REPLY 
matches the REQUEST if SEQUENCE.REPLY is greater than or equal to 
SEQUENCE.REQUEST?
-- 

john noerenberg
   ----------------------------------------------------------------------
   The Constitution of the United States is a law for rulers and people
   equally in war and in peace, and covers with the shield of its
   protection all classes of men, at all times, and under all
   circumstances.
   -- U.S. Supreme Court, Ex Parte Milligan, 71 U.S. 2, 120-121 (1866)
   ----------------------------------------------------------------------
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: "Tim Hare" <[email-masked]>
Date: Fri, 18 Jan 2008 21:27:31 -0500

My understanding is that the VEVENT matches if UID is the same, and SEQUENCE
is the same. 

Reasoning logically, rather than reading the spec, if you are the organizer
and you receive a reply with a SEQUENCE higher than yours, something is
wrong (for example, your calendar store has been restored from a backup
before all REPLY items were received and processed).  If the SEQUENCE is
lower, then the client is responding to a previous REQUEST; we can (should
we?) presume you sent a new REQUEST when whatever changed happened that
caused SEQUENCE to be incremented, and therefore you might want to wait
until the response to that revision arrives.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of John W
Noerenberg II
Sent: Friday, January 18, 2008 5:59 PM
To: [email-masked]
Subject: [Ietf-calsify] Interpreting 2.1.5 Message Sequencing in rfc2446bis

2.1.5 3. says:

"Attendees" send "REPLY" messages to the "Organizer".  For replies where the
"UID" property value is the same, the value of the "SEQUENCE" property
indicates the revision of the component to which the "Attendee" is replying.
The reply with the highest numeric value for the "SEQUENCE" property
obsoletes all other replies with lower values.

Should I take this to mean that the VEVENT in a REPLY only matches the
VEVENT in the corresponding REQUEST if both the value of UID and SEQUENCE in
each message match?  Or should it be that the REPLY matches the REQUEST if
SEQUENCE.REPLY is greater than or equal to SEQUENCE.REQUEST?
-- 

john noerenberg

---

From: Eliot Lear <[email-masked]>
Date: Sat, 19 Jan 2008 13:33:49 +0100

Hello John,
> VEVENT in the corresponding REQUEST if both the value of UID and 

There are two contexts to consider - that of the PARTICIPANT and that of 
the ORGANIZER.  The PARTICIPANT is REPLYing to a specific VEVENT with a 
specific SEQUENCE, and so there is not interpreting involved at that 
end.  The ORGANIZER receiving REPLYs can use SEQUENCE to detect out of 
order messages, such that if a REPLY with a lower SEQUENCE number is 
received subsequent to one with a higher SEQUENCE, the REPLY with the 
lower value can be safely ignored.

The converse is *not* necessarily true: if an  ORGANIZER sends an UPDATE 
that bumped the SEQUENCE and then received a REPLY with lower SEQUENCE, 
the ORGANIZER should consider whether he or she reset PARTSTAT on the 
later SEQUENCE in order to make a sane decision as to how to consider 
the PARTICIPANT's REPLY.  If the ORGANIZER did not reset PARTSTAT, then 
one may not wish to simply ignore the REPLY.  Indeed the text currently 
says the following:

>    The value of the "SEQUENCE" property contained in a response from an
>    "Attendee" may not always match the "Organizer's" revision.
>    Implementations may choose to have the CUA indicate to the CU that
>    the response is to an entry that has been revised and allow the CU to
>    decide whether or not to accept the response.

IMHO if the ORGANIZER set PARTSTAT to "NEEDS-ACTION" in a subsequent 
UPDATE, then the REPLY should probably not be accepted.  Do others agree 
and should we clarify this?

Eliot

---

From: "Tim Hare" <[email-masked]>
Date: Sat, 19 Jan 2008 16:51:45 -0500

A case _could_ be made, that when you as ORGANIZER receive a REPLY with a
lower SEQUENCE, that you accept it and set PARTSTAT to reflect the status as
"what we know so far".  This reflects how meeting organization works in the
phone-call-and-pencil (PCAP) system.  

Tim Hare

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Saturday, January 19, 2008 7:34 AM
To: John W Noerenberg II
Cc: [email-masked]
Subject: Re: [Ietf-calsify] Interpreting 2.1.5 Message Sequencing in
rfc2446bis

Hello John,
> 2.1.5 3. says:
>
> "Attendees" send "REPLY" messages to the "Organizer".  For replies 
> where the "UID" property value is the same, the value of the 
> "SEQUENCE" property indicates the revision of the component to which 
> the "Attendee" is replying.  The reply with the highest numeric value 
> for the "SEQUENCE" property obsoletes all other replies with lower 
> values.
>

There are two contexts to consider - that of the PARTICIPANT and that of the
ORGANIZER.  The PARTICIPANT is REPLYing to a specific VEVENT with a specific
SEQUENCE, and so there is not interpreting involved at that end.  The
ORGANIZER receiving REPLYs can use SEQUENCE to detect out of order messages,
such that if a REPLY with a lower SEQUENCE number is received subsequent to
one with a higher SEQUENCE, the REPLY with the lower value can be safely
ignored.

The converse is *not* necessarily true: if an  ORGANIZER sends an UPDATE
that bumped the SEQUENCE and then received a REPLY with lower SEQUENCE, the
ORGANIZER should consider whether he or she reset PARTSTAT on the later
SEQUENCE in order to make a sane decision as to how to consider the
PARTICIPANT's REPLY.  If the ORGANIZER did not reset PARTSTAT, then one may
not wish to simply ignore the REPLY.  Indeed the text currently says the

>    decide whether or not to accept the response.

IMHO if the ORGANIZER set PARTSTAT to "NEEDS-ACTION" in a subsequent UPDATE,
then the REPLY should probably not be accepted.  Do others agree and should
we clarify this?

Eliot

---

From: John W Noerenberg II <[email-masked]>
Date: Mon, 21 Jan 2008 16:20:57 -0800

At 1:33 PM +0100 1/19/08, Eliot Lear wrote:
>>the VEVENT in the corresponding REQUEST if both the value of UID 
>>and SEQUENCE in each message match?  Or should it be that the REPLY 
>There are two contexts to consider - that of the PARTICIPANT and 
>that of the ORGANIZER.

Yup.  I should have made it clear I was speaking from the perspective 
of the ORGANIZER's interpreting a PARTICIPANT's reply.

>The PARTICIPANT is REPLYing to a specific VEVENT with a specific 
>SEQUENCE, and so there is not interpreting involved at that end. 
>The ORGANIZER receiving REPLYs can use SEQUENCE to detect out of 
>received subsequent to one with a higher SEQUENCE, the REPLY with 
>the lower value can be safely ignored.
>
>The converse is *not* necessarily true: if an  ORGANIZER sends an 
>UPDATE that bumped the SEQUENCE and then received a REPLY with lower 
>SEQUENCE, the ORGANIZER should consider whether he or she reset 
>PARTSTAT on the later SEQUENCE in order to make a sane decision as 
>to how to consider the PARTICIPANT's REPLY.  If the ORGANIZER did 
>not reset PARTSTAT, then one may not wish to simply ignore the 
>REPLY.  Indeed the text currently says the following:
>
>UPDATE, then the REPLY should probably not be accepted.  Do others 
>agree and should we clarify this?

Suppose a PARTICIPANT replies with a SEQUENCE value greater than the 
ORGANIZER's value.  Should the ORGANIZER send some sort of error 
status to the PARTICIPANT?  Perhaps better, the CUA should notify the 
CU there's a problem.  Otherwise a malicious ATTENDEE CUA could cause 
the organizer's CUA to spew error messages.

I don't mean to be disingenuous, but what do you mean by UPDATE? 
AFAIK, it's not a term of art in the iCalendar world - and there 
probably are too many ways to construct a message some reader would 
believe was an update message of one kind or another. :-)

But for the sake of answering your question, I'll just consider 
METHOD:REPLY.  You can tell me if I got it right. ;-)  Essentially, I 
agree. If the ORGANIZER sets an ATTENDEE's PARTSTAT=NEEDS-ACTION and 
receives a REPLY from that ATTENDEE which has a value for SEQUENCE 
not only lower, but different than the REQUEST from the ORGANIZER, 
then the ORGANIZER can discard the REPLY.
-- 

john noerenberg

---

From: John W Noerenberg II <[email-masked]>
Date: Mon, 21 Jan 2008 16:38:39 -0800

>At 2:08 PM -0800 1/21/08, John  W Noerenberg II wrote:
>>IMHO if the ORGANIZER set PARTSTAT to "NEEDS-ACTION" in a 
>>subsequent UPDATE, then the REPLY should probably not be accepted. 
>>Do others agree and should we clarify this?

Forgive me if I'm dragging out a dead horse...

Why do we have both PARTSTAT and RSVP parameters?  Is there ever a 
condition in a REQUEST that a CUA would set PARTSTAT=NEEDS-ACTION and 
not set RSVP=TRUE?  Is there ever a condition  where a CUA would omit 
PARTSTAT=NEEDS-ACTION and could not include an RSVP=FALSE?

If it were up to me, I'd get rid of RSVP.  I know the RSVP parameter 
is used.  In 2445bis and 2446bis, I'd say the RSVP parameter and it's 
value have no semantic meaning.  It's presence in an ATTENDEE 
property is not an error, but it's use is discouraged.

This is just my way of striking a blow for brevity in VEVENTs. ;-)
-- 

john noerenberg

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 21 Jan 2008 21:38:17 -0500

Hi John,

--On January 21, 2008 4:38:39 PM -0800 John W Noerenberg II 
<[email-masked]> wrote:

> condition in a REQUEST that a CUA would set PARTSTAT=NEEDS-ACTION and not
> set RSVP=TRUE?  Is there ever a condition  where a CUA would omit
> If it were up to me, I'd get rid of RSVP.  I know the RSVP parameter is
> used.  In 2445bis and 2446bis, I'd say the RSVP parameter and it's value
> have no semantic meaning.  It's presence in an ATTENDEE property is not
> an error, but it's use is discouraged.
>

Actually I think a valid situation is to have PARTSTAT=ACCEPTED and 
RSVP=TRUE. That is called out in iTIP as a case of an organizer requesting 
a participant to re-confirm their status for the meeting (see section 
3.2.2.7). So at least in that case there is a need for RSVP separate from 
the PARTSTAT value. Though you could argue that the organizer should just 
set PARTSTAT back to NEEDS-ACTION.

On your point, it would seem natural to say that anytime PARTSTAT is 
NEEDS-ACTION that a reply is expected. However, if ROLE is set to indicate 
a non-required participant, perhaps the organizer does not care about 
whether a reply is returned or not.

I'll note that one of the things I did in the Apple CalDAV server was to 
require the presence of RSVP=TRUE for invites to auto-responding resources 
(e.g. locations) that the server itself generated iTIP replies for. This 
did cause at least one client to change its behavior because it was not 
setting RSVP=TRUE. One could argue that was too strict a reading of the RFC 
but I think its a fair reading of the current state.

-- 
Cyrus Daboo

---

From: John W Noerenberg II <[email-masked]>
Date: Tue, 22 Jan 2008 10:30:21 -0800

At 9:38 PM -0500 1/21/08, Cyrus Daboo wrote:
>RSVP=TRUE. That is called out in iTIP as a case of an organizer 
>requesting a participant to re-confirm their status for the meeting 
>(see section 3.2.2.7). So at least in that case there is a need for 
>RSVP separate from the PARTSTAT value. Though you could argue that 
>the organizer should just set PARTSTAT back to NEEDS-ACTION.

That's my argument.  I think 3.2.2.7 can safely be deleted.  There's 
nothing preventing the ORGANIZER from setting PARTSTAT=NEEDS-ACTION 
for an ATTENDEE in a subsequent REQUEST, regardless of the value of 
PARTSTAT for an ATTENDEE in a previous REPLY.

>NEEDS-ACTION that a reply is expected. However, if ROLE is set to 
>indicate a non-required participant, perhaps the organizer does not 
>care about whether a reply is returned or not.

On a REQUEST, If ROLE=OPT-PARTICIPANT or NON-PARTICIPANT, then 
omitting the PARTSTAT parameter if no response is required is 
legitimate.

What underlies my argument is my unwillingness to anthropomorphize 
the ORGANIZER.  If the ORGANIZER requires a response, then 
PARTSTAT=NEEDS-ACTION fills the bill.  Whether the organizer cares is 
out-of-scope, I claim.

>
>I'll note that one of the things I did in the Apple CalDAV server 
>was to require the presence of RSVP=TRUE for invites to 
>auto-responding resources (e.g. locations) that the server itself 
>generated iTIP replies for. This did cause at least one client to 
>change its behavior because it was not setting RSVP=TRUE. One could 
>argue that was too strict a reading of the RFC but I think its a 
>fair reading of the current state.

Was the client not responding to PARTSTAT=NEEDS-ACTION?

I suppose one could say that setting PARSTAT=NEEDS-ACTION and 
RSVP=TRUE amounts to the ORGANIZER really, really needs a response. 
But now we're sliding down the slippery slope of 
anthropomorphization. ;-)

-- 

john noerenberg
   ----------------------------------------------------------------------
   While the belief we  have found the Answer can separate us
   and make us forget our humanity, it is the seeking that continues
   to bring us together, that makes and keeps us human.
   -- Daniel J. Boorstin, "The Seekers", 1998
   ----------------------------------------------------------------------
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: John W Noerenberg II <[email-masked]>
Date: Tue, 22 Jan 2008 12:56:18 -0800

At 9:38 PM -0500 1/21/08, Cyrus Daboo wrote:
>One could argue that was too strict a reading of the RFC but I think 
>its a fair reading of the current state.

I'd go a little further and say this is an incorrect reading.  RSVP 
is always optional for VEVENTS.  So a CUA or CSA that demands it has 
gone too far. :-)

Curiously, I did find references in VTODOs that make it mandatory. 
I'm not liking that.

(It's probably more appropriate to ask this in the context of 
calconnect, but...) Is anybody doing anything with VTODOs?  As a 
creator and consumer of iCalendar objects, I've never encountered 
one.  I notice that CalConnect's test suite mentions them not at all. 
I confess I'm leery of loping off VTODO and VJOURNAL, but it's a 
tempting thought.  It would certainly reduce my angst over RSVP.
-- 

john noerenberg
   ----------------------------------------------------------------------
   All actions are wrought by the qualities of nature only.
   The self, deluded by egoism, thinketh, "I am the doer."
   -- Bhagavad Gita
   ----------------------------------------------------------------------
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: John W Noerenberg II <[email-masked]>
Date: Mon, 28 Jan 2008 19:09:12 -0800

>PARTSTAT for an ATTENDEE in a previous REPLY.

Judging by the resounding silence, no else seems to think this worth 
discussion.

Is it because most everyone thinks this is too late in the game to 
make changes like this; is it because y'all think I'm crazy  (I've 
been called worse, I can handle it. :-)); or is it something in 
between?
-- 

john noerenberg
   --------------------------------------------------------------------
    "We need not to be left alone.  We need to be really
     bothered once in a while."
   -- Ray Bradbury, Farhenheit 451, 1953
   --------------------------------------------------------------------
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: "Tim Hare" <[email-masked]>
Date: Mon, 28 Jan 2008 22:27:13 -0500

I cannot seem to find the latest RFC2445 document at IETF.  Could someone
please post the correct URL since I must be doing something dumb?

Thanks

Tim Hare

---

From: "Darryl Champagne" <[email-masked]>
Date: Mon, 28 Jan 2008 23:56:48 -0500

Hi,

I believe the last version posted was:

	Title		: Internet Calendaring and Scheduling Core Object
Specification (iCalendar)
	Author(s)	: B. Desruisseaux
	Filename	: draft-ietf-calsify-rfc2445bis-07.txt
	Pages		: 177
	Date		: 2007-7-9

Per IETF policy, it is deleted from the www.ietf.org/internet-drafts area
after 6 months (which is why the link no longer works), but is still
available in the tools /id area.

The drafts are available via the Calsify status page:
http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/

Specifically, the html version is at
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-07 or the text
version at http://tools.ietf.org/id/draft-ietf-calsify-rfc2445bis-07.txt.

dgc

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tim Hare
Sent: Monday, January 28, 2008 10:27 PM
To: [email-masked]
Subject: [Ietf-calsify] RFC2445 latest IETF document?

Thanks

Tim Hare

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 01 Feb 2008 00:15:18 -0500

Hi John,

John W Noerenberg II wrote:
> not set RSVP=TRUE?

Here's one:

The "Organizer" of a VTODO is requesting an updated status from an 
"Attendee" that currently has PARTSTAT=IN-PROCESS. The "Attendee" will 
either reply with PARTSTAT=COMPLETED, or with PARTSTAT=IN-PROCESS with 
perhaps a greater PERCENT-COMPLETE value.

Cheers,
Bernard

> Is there ever a condition  where a CUA would omit 

Date: Fri, 01 Feb 2008 00:15:18 -0500
From: Bernard Desruisseaux <[email-masked]>
To: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] As long as we're talking about PARTSTAT...
Cc: [email-masked]

Hi John,

John W Noerenberg II wrote:
> not set RSVP=TRUE?

Here's one:

The "Organizer" of a VTODO is requesting an updated status from an 
"Attendee" that currently has PARTSTAT=IN-PROCESS. The "Attendee" will 
either reply with PARTSTAT=COMPLETED, or with PARTSTAT=IN-PROCESS with 
perhaps a greater PERCENT-COMPLETE value.

Cheers,
Bernard

> Is there ever a condition  where a CUA would omit 

Date: Thu, 31 Jan 2008 23:59:03 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Mike Douglass <[email-masked]>
Subject: Re: [Ietf-calsify] dtstamp twice
Cc: Calsify <[email-masked]>

Fixed.

Thanks,
Bernard

Mike Douglass wrote:
> Maybe corrected but draft 7 has dtstamp and uid both required and 
> optional for freebusy
> 
>                   ; the following are REQUIRED,
>                   ; but MUST NOT occur more than once
> 
>                   dtstamp / uid /
> 
>                   ; the following are OPTIONAL,
>                   ; but MUST NOT occur more than once
> 
>                   contact / dtstart / dtend / duration / dtstamp /
>                   organizer / uid / url /
> 
> 

Date: Thu, 31 Jan 2008 23:29:46 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Aki Niemi <[email-masked]>
Cc: ietf-calsify <[email-masked]>
Subject: [Ietf-calsify] Re: Chair review of draft-ietf-calsify-rfc2445bis

Hi Aki,

Aki Niemi wrote:
> All,
> 
> I've now reviewed RFC2445-bis, and am currently working on the PROTO
> writeup, which is a document that accompanies the draft as we request
> publication.
> 
> I'll also send some typos and such to Bernard privately.
> 
> Cheers,
> Aki
> 
> 
> Technical:
> ==========
> 
> * Sec 3.2.3: an implementation should treat an unrecognized CUTYPE value
> as UNKNOWN as opposed to INDIVIDUAL:
> 
>         OLD:
>         
>         Applications MUST treat x-name and iana-token value they don't
>         recognized the same way as the INDIVIDUAL value. 
>         
>         NEW:
>         
>         Applications MUST treat x-name and iana-token value they don't
>         recognized the same way as the UNKNOWN value. 

Done.

>         
> * Section 3.2.19: treating unknown VALUE data types. Rather than
> treating unrecognized values as TEXT, I think the draft should instruct
> implementations to ignore them:
> 
>         OLD: 
>         
>         Applications MUST treat x-name and iana-token value they don't
>         recognized the same way as the TEXT value.
>         
>         NEW:
>         
>         Applications MUST ignore x-name and iana-token values that they
>         don't recognize.

Changed with the text provided by Cyrus, that is:

    Applications MUST preserve the value data for x-name and iana-token
    values that they don't recognize without attempting to interpret or
    parse the value data.

> 
> * Sec 3.2.4/3.2.5: the DELEGATED-TO and DELEGATED-FROM parameters say
> that the cal-address MUST be a mailto URI. However, the actual
> definition of cal-address is more liberal; it says MUST be a mailto URI
> but only when email is used as transport. 
> 
> Assuming DELEGATED-* can be used with any transport, either their
> definition needs to add the same transport disclaimer, or the MUST needs
> to be removed altogether (and rely only on cal-address definition here)

This issue was discussed during IETF-65.

Slide 7:
http://www.ietf.org/proceedings/06mar/slides/calsify-1/sld7.htm

Minutes [From 03:08:46 to 03:15:38]:
http://tools.ietf.org/wg/calsify/minutes?item=minutes65.html

Back then the idea was to remove these restrictions on mailto URI
and to specify a set of URI types that should be allowed. Given
that we never got around to define this set, I will simply remove
the MUST specified for DELEGATED-TO and DELEGATED-FROM and rely
only on cal-address definition.

> 
> * Sec 3.6.6: alarm component. I think it is useful to add a short note
> about dealing with alarm components from untrusted sources. I think
> there used to be some "handwaiving" about that in the security
> considerations, but I think it got removed. Suggest something like:
> 
>         OLD:
>         
>         The "ACTION" property is used within the "VALARM" calendar
>         component to specify the type of action invoked when the alarm
>         is triggered. The "VALARM" properties provide enough information
>         for a specific action to be invoked. It is typically the
>         responsibility of a "Calendar User Agent" (CUA) to deliver the
>         alarm in the specified fashion. An "ACTION" property value of
>         AUDIO specifies an alarm that causes a sound to be played to
>         alert the user; DISPLAY specifies an alarm that causes a text
>         message to be displayed to the user; and EMAIL specifies an
>         alarm that causes an electronic email message to be delivered to
>         one or more email addresses.
>         
>         NEW:
>         
>         The "ACTION" property is used within the "VALARM" calendar
>         component to specify the type of action invoked when the alarm
>         is triggered. The "VALARM" properties provide enough information
>         for a specific action to be invoked. It is typically the
>         responsibility of a "Calendar User Agent" (CUA) to deliver the
>         alarm in the specified fashion. An "ACTION" property value of
>         AUDIO specifies an alarm that causes a sound to be played to
>         alert the user; DISPLAY specifies an alarm that causes a text
>         message to be displayed to the user; and EMAIL specifies an
>         alarm that causes an electronic email message to be delivered to
>         one or more email addresses.
>         
>                 Note: implementations should carefully consider whether
>                 they accept alarm components from untrusted sources,
>                 e.g., when importing calendar objects from external
>                 sources. One reasonable policy is to always ignore alarm
>                 components that the calendar user has not set herself,
>                 or at least ask for confirmation in such a case.

Done.  I added the note at the very end of the "Description:" part
of VALARM.

>         
> * Section 8.1, 2nd sentence: what does this mean? Suggest removing it.
> 
>> However, the implementation of the memo is in no way limited solely as
>> a MIME content type.  

Done.

> 
> 
> Structure:
> ==========
> 
> * Sec 3: it would help readability a lot to explain in the introduction
> some basics of iCalendar, and how exactly the section that follows is
> structured. Currently, it's easy to miss the bigger picture, as the
> section jumps directly into content lines formatting, and the data types
> used in properties, without a clear picture as to where and how they
> will be used.
> 
> My proposal is to add the following passage to the top of Section 3:
> 
>         OLD:
>         
>         The following sections define the details of a Calendaring and
>         Scheduling Core Object Specification. This information is
>         intended to be an integral part of the MIME content type
>         registration. In addition, this information can be used
>         independent of such content registration. In particular, this
>         memo has direct applicability for use as a calendaring and
>         scheduling exchange format in file-, memory- or network-based
>         transport mechanisms.
>         
>         NEW:
>         
>         The following sections define the details of a Calendaring and
>         Scheduling Core Object Specification. The Calendaring and
>         Scheduling Core Object is a collection of calendaring and
>         scheduling information. Typically, this information will consist
>         of an iCalendar stream with one or more iCalendar objects. The
>         body of the iCalendar object consists of a sequence of calendar
>         properties and one or more calendar components.
>         
>         Section 3.1. defines the content line format; Section 3.2.
>         defines the property parameter format; Section 3.3. defines the
>         data types for property values; Section 3.4. defines the
>         iCalendar object format; Section 3.5. defines the iCalendar
>         property format; Section 3.6. defines the calendar component
>         format; Section 3.7. defines calendar properties; and Sectiopn
>         3.8. defines calendar component properties.
>         
>         This information is intended to be an integral part of the MIME
>         content type registration. In addition, this information can be
>         used independent of such content registration. In particular,
>         this memo has direct applicability for use as a calendaring and
>         scheduling exchange format in file-, memory- or network-based
>         transport mechanisms.

Done.

> 
> * Sec 3.3.1:
> 
>> No additional content value encoding (i.e., BACKSLASH character
>> encoding) is defined for this value type.
> 
> This is the first time BACKSLASH character encoding is mentioned. What
> is it? Suggest adding a forward reference to Sec 3.3.11., where it is
> defined.

Done.

> 
> Nits:
> =====
> 
> * Section 2, first sentence: RFC2119 doesn't have a "NOT RECOMMENDED"
> key word. (Caught by I-D nits tool)

Check Errata ID 499.
http://www.rfc-editor.org/errata.php

The idnits tool should be fixed to allow this.

Thanks,
Bernard

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] Imprecise and alternative events foriCalendarandiTIP
Date: Wed, 30 Jan 2008 11:23:40 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_00F2_01C86332.92B502B0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

I was trying to come up with solutions that don't require adding new
component types, since getting to simplification and standardization of the
current components has been such a long and winding road. 
 
I take your point about transparency not reflecting the fact that you're
"busy".  It's a general problem in calendaring tools - there's not an easy
way to say things like:
 
"I'm POTENTIALLY busy during that time, please don't schedule then" or
"I've got something planned during that time, but of course my boss can
override that".
 
I guess the best thing for the individual, currently, for your use case,
would be to mark the time as busy from 5pm to 11:59pm which at least has the
positive effect of preventing over-scheduling; and then using your CUA to
reduce the endpoints of the appointment as it becomes clearer exactly when
it will happen.
 
Tim Hare

------=_NextPart_000_00F2_01C86332.92B502B0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3243" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008>I was trying to come up with solutions that =
don't=20
require adding new component types, since getting to simplification and=20
standardization of the current components has been such a long and =
winding road.=20
</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008>I take your point about transparency not =
reflecting the=20
fact that you're "busy".&nbsp; It's a general problem in calendaring =
tools -=20
there's not an easy way to say things like:</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008>"I'm POTENTIALLY busy during that time, =
please don't=20
schedule then" or</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008>"I've got something planned during that time, =
but of=20
course my boss can override that".</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008>I guess the best thing for the individual, =
currently,=20
for your use case, would be to mark the time as busy from 5pm to 11:59pm =
which=20
at least has the positive effect of preventing over-scheduling; and then =
using=20
your CUA to reduce the endpoints of the appointment as it becomes =
clearer=20
exactly when it will happen.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Tim Hare</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Interested Bystander,=20
Non-Inc.</FONT></DIV>
<DIV>&nbsp;</DIV><BR></BODY></HTML>

------=_NextPart_000_00F2_01C86332.92B502B0--

Date: Wed, 30 Jan 2008 09:51:31 -0500
From: Mike Douglass <[email-masked]>
To: Calsify <[email-masked]>
Subject: [Ietf-calsify] dtstamp twice

Maybe corrected but draft 7 has dtstamp and uid both required and 
optional for freebusy

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

                   dtstamp / uid /

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

                   contact / dtstart / dtend / duration / dtstamp /
                   organizer / uid / url /

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] Imprecise and alternative events for iCalendarandiTIP
Date: Tue, 29 Jan 2008 20:22:25 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_00BF_01C862B4.AAC71BF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Would the "pencil in" function of a VEVENT for four hours with TRANSP:
TRANSPARENT provide a similar function to what is described in your use =
case
for VIMPRECISEEVENT?=20
=20
Similarly, for scheduling, would it be simpler to define iTIP such that =
a
METHOD: REQUEST for scheduling an appointment, which included VFREEBUSY
components; i.e. " I'd like to schedule an appointment, and I'm free =
during
these times",  would indicate the preference of the time to be scheduled =
by
the order of the VFREEBUSY components? That would allow for an unlimited
number of potential openings for scheduling, without having to have a
defined RANK property, and it's certainly not that difficult for
implementations to ennumerate the VFREEBUSY components in that way.
=20
=20
=20
Tim Hare
Interested Bystander, Non-Inc.
=20

  _____ =20

From: [email-masked]
[mailto:[email-masked]] On Behalf Of F=E1bio =
Henrique
da Silva
Sent: Tuesday, January 29, 2008 7:38 PM
To: Nigel Swinson
Cc: [email-masked]
Subject: Re: [Ietf-calsify] Imprecise and alternative events for
iCalendarandiTIP

Dear Nigel,

Thanks for the comments! Yes, I think that, even with the difficulties
presented on the appendix of the draft, we should look for solutions
preserving backward compatibility. It would be nice to hear some =
opinions
about these alternative design solutions you proposed =3Do)

I would only point that, apart from the discussion on the number of =
levels
(0-100 is only an initial hint based on PERCENT-COMPLETE), the concept =
of
rank is relevant, since some event descriptions and time ranges must be
marked as more appropriate/desired/likely to be scheduled/... than =
others.

But the primary purpose of the draft is that: to start a discussion on =
how
to give more flexibility to iCalendar in a standard way, pointing that =
such
mechanisms would be really useful for scheduling negotiation.

Cheers,

F=E1bio.

On Jan 24, 2008 3:09 PM, Nigel Swinson <[email-masked]> =
wrote:

       Title           : Imprecise and alternative events for iCalendar =
and
iTIP
       Author(s)       : F. Silva, R. Drummond
       Filename        : draft-silva-events-01.txt
       Pages           : 55=20
       Date            : 2007-12-21

This has long been something that has annoyed me about digital =
calendaring,
so I'm delighted to see that this work is proceeding :o)  I've finally =
found
the time to read the document, and have the following comments.
=20
3.1.  Imprecise Event Component

Given that calendars are being shared so much between so many clients, I
feel uneasy about the lack of backward compatibility expressed in the
document as it stands.  Suppose I was to arrange with my mum to have =
dinner
tonight, but we hadn't yet agreed a time.  I would then "guess" than the
meal would start somewhere between 5pm and 8pm and last until midnight.  =
To
begin with I don't think I can say the event will last until midnight,
regardless of it's start time, so lets assume I say it is going to last =
4
hours.  Writing this as a VIMPRECISEEVENT I think I'd have to write this =
as:
=20
        BEGIN:VIMPRECISEEVENT
        UID:[email-masked]
        DTSTAMP:20080124T160825Z
        SUMMARY:Dinner with my mum
        DURATION:PT4H
        BEGIN:VFREEBUSY
        UID:[email-masked]
        DTSTAMP:20080124T160825Z
        FREEBUSY;FBTYPE=3DFREE:20080124T170000Z/20080125T000000Z
        END:VFREEBUSY
        END:VIMPRECISEEVENT
=20
If I look at this inside a client that supports VIMPRECISEEVENT then =
perhaps
it'll show it with appropriate annotation, but then when I view it in a
client that doesn't support it I'll see absolutely nothing at all, =
implying
that my evening is free. =20
=20
I expected imprecise events to be specified by some modifier on the
DTSTART/DTEND properties.  ie something like this (which also allows me =
to
say it ends at midnight):
=20
        BEGIN:VIMPRECISEEVENT
        UID:[email-masked]
        DTSTAMP:20080124T160825Z
        SUMMARY:Dinner with my mum
        DURATION:PT4H
        DTSTART;RANGE=3D3H:20080124170000Z
        DTEND:20081225000000Z
        END:VIMPRECISEEVENT
=20
Now when I look at this in a client that doesn't understand the RANGE
parameter on DTSTART, it'll show up as busy from 5pm-12pm, and in a =
client
that does, it can show a "fuzzy" start from 5pm-8pm, and then definately
busy up until 12pm. =20
=20
A freebusy lookup could also then return meaningful data from both =
clients,
whereas you've specified that VIMPRECISEEVENT is invisible to free busy
lookups.  The one that didn't support RANGE for DTSTART might return =
busy
from 8-12, while the other could return:
=20
        BEGIN:VFREEBUSY
        UID:[email-masked]
        DTSTAMP:20080124T160825Z
        =
FREEBUSY;FBTYPE=3DBUSY-TENTATIVE:20080124T170000Z/20080124T200000Z
        FREEBUSY;FBTYPE=3DBUSY:20080124T200000Z/20080125T000000Z
        END:VFREEBUSY

Admittedly adding a RANGE parameter to DTSTART and DTEND would not be as
flexibly as specifying a duration and a list of constraints by means of
free/busy, but it has the advantage of being far easier to apply to an
existing iCalendar parser, rather than having to deal with an entirely =
new
iCalendar component, so I think it might get a substantially bigger =
uptake.
=20
WRT to an event that specifies a medical appointment that occurs within =
one
of several time periods (the second example in the spec), that could =
then be
implemented either by means of STATUS:TENTATIVE on an appointment with =
an
RRULE, or else by using VALTERNATIVEEVENTS.
=20
3.2.  Alternative Events Component

In the interests of parser re-use, rather than specifying the default =
event
properties in the alternativeeventsprop and then overridden in the =
*eventc
I'd be inclined to specify them by means of a "master event" section, of
type eventc.  Then if some new event property comes out, only the parser =
for
eventc needs to be updated, rather than also the alternativeeventsprop
collection.  One slight problem is that for a vevent to be valid, it =
must
have a dtstart, so I'd suggest we just refer to one of our alternative
events as our "master event" that contains default properties. The =
example
would become something like:
=20
      BEGIN:VALTERNATIVEEVENTS
      UID:[email-masked]
      DTSTAMP:20071005T133225Z
      DEFAULTPROPERTIES:[email-masked]
      BEGIN:VEVENT
      UID:[email-masked]
      DTSTAMP:20071005T133225Z
      DTSTART:20071005T133225Z
      SUMMARY:Quick interop test
      COMMENT:Trying the options that seem most likely to be accepted...
      END:VEVENT
      BEGIN:VEVENT
      UID:[email-masked]
      DTSTAMP:20071005T133225Z
      DTSTART:20080406T090000Z
      DTEND:20080405T120000Z
      RANK:100
      COMMENT:It would be perfect if we could meet at that same time!
      END:VEVENT
      BEGIN:VIMPRECISEEVENT
      ..etc...
      END:VIMPRECISEEVENT
      END:VALTERNATIVEEVENTS

=20
3.3/3.4/3.5  Minimum/Maximum Granularity/Rank Component Property
=20
I think these are icing that I'd be inclined to ignore in an initial
implementation.  Even writing the gui and trying to communicate the =
concepts
would be challenging.  I'm also not sure why it's worth saying that Rank =
is
defined as a %.  Why not just an unsigned number?  Then if you want to
communicate it as a % you can evaluate the max/min Rank, and convert to =
a %.
I'm sure 100 levels is plenty, but for the sake of writing a =
specification,
I don't see why you couldn't just say it's an arbitrary number.  It =
would be
very annoying to find you needed more levels, but the standard didn't =
permit
it.
=20
Cheers
=20
Nigel

------=_NextPart_000_00BF_01C862B4.AAC71BF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3243" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D216361401-30012008>Would the "pencil in" function of a VEVENT =
for four=20
hours with TRANSP: TRANSPARENT provide a similar function to what is =
described=20
in your use case for VIMPRECISEEVENT? </SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D216361401-30012008></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D216361401-30012008>Similarly, for scheduling, would it be =
simpler to=20
define iTIP such that a METHOD: REQUEST for scheduling an appointment, =
which=20
included VFREEBUSY components; i.e. " I'd like to schedule an =
appointment, and=20
I'm free during these times",&nbsp; would indicate the preference of the =
time to=20
be scheduled by the order of the VFREEBUSY components? That would allow =
for an=20
unlimited number of potential openings for scheduling, without having to =
have a=20
defined RANK property, and it's certainly not that difficult for =
implementations=20
to ennumerate the VFREEBUSY components in that way.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D216361401-30012008></SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Tim Hare</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Interested Bystander,=20
Non-Inc.</FONT></DIV>
<DIV>&nbsp;</DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of =
</B>F=E1bio=20
Henrique da Silva<BR><B>Sent:</B> Tuesday, January 29, 2008 7:38=20
PM<BR><B>To:</B> Nigel Swinson<BR><B>Cc:</B>=20
[email-masked]<BR><B>Subject:</B> Re: [Ietf-calsify] =
Imprecise=20
and alternative events for iCalendarandiTIP<BR></FONT><BR></DIV>
<DIV></DIV>Dear Nigel,<BR><BR>Thanks for the comments! Yes, I think =
that, even=20
with the difficulties presented on the appendix of the draft, we should =
look for=20
solutions preserving backward compatibility. It would be nice to hear =
some=20
opinions about these alternative design solutions you proposed =
=3Do)<BR><BR>I=20
would only point that, apart from the discussion on the number of levels =
(0-100=20
is only an initial hint based on PERCENT-COMPLETE), the concept of rank =
is=20
relevant, since some event descriptions and time ranges must be marked =
as more=20
appropriate/desired/likely to be scheduled/... than others.<BR><BR>But =
the=20
primary purpose of the draft is that: to start a discussion on how to =
give more=20
flexibility to iCalendar in a standard way, pointing that such =
mechanisms would=20
be really useful for scheduling=20
negotiation.<BR><BR>Cheers,<BR><BR>F=E1bio.<BR><BR>
<DIV class=3Dgmail_quote>On Jan 24, 2008 3:09 PM, Nigel Swinson &lt;<A=20
href=3D"mailto:[email-masked]"=20
target=3D_blank>[email-masked]</A>&gt; wrote:<BR>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
  <DIV bgcolor=3D"#ffffff">
  <DIV>
  <BLOCKQUOTE=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: rgb(0,0,0) 2px solid; MARGIN-RIGHT: =
0px">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Title=20
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : Imprecise and alternative =
events for=20
    iCalendar and iTIP<BR>&nbsp; &nbsp; &nbsp; &nbsp;Author(s) &nbsp; =
&nbsp;=20
    &nbsp; : F. Silva, R. Drummond<BR>&nbsp; &nbsp; &nbsp; =
&nbsp;Filename &nbsp;=20
    &nbsp; &nbsp; &nbsp;: draft-silva-events-01.txt<BR>&nbsp; &nbsp; =
&nbsp;=20
    &nbsp;Pages &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : 55 <BR>&nbsp; =
&nbsp; &nbsp;=20
    &nbsp;Date &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;:=20
  2007-12-21</BLOCKQUOTE></DIV>
  <DIV><FONT face=3DArial size=3D2>This has long been something that has =
annoyed me=20
  about digital calendaring, so I'm delighted to see that this work is=20
  proceeding :o)&nbsp; I've finally found the time to read the document, =
and=20
  have the following comments.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><SPAN><A=20
  =
name=3D117c2dc35508f571_117acfd71130c051_section-3.1><B>3.1</B></A><B>.&n=
bsp;=20
  Imprecise Event Component</B></SPAN><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>Given that calendars are being shared =
so much=20
  between so many clients, I feel uneasy about the lack of backward=20
  compatibility expressed in the document as it stands.&nbsp; Suppose I =
was to=20
  arrange with my mum to have dinner&nbsp;tonight, but we hadn't yet =
agreed a=20
  time.&nbsp; I would then "guess" than the meal would start somewhere =
between=20
  5pm and 8pm and last until midnight.&nbsp; To begin with I don't think =
I can=20
  say the&nbsp;event will last until midnight, regardless of it's start =
time, so=20
  lets assume I say it is going to last 4 hours.&nbsp; Writing this as a =
<FONT=20
  size=3D3>VIMPRECISEEVENT </FONT></FONT><FONT face=3DArial size=3D2>I =
think I'd have=20
  to write this as:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  BEGIN:VIMPRECISEEVENT<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =

  href=3D"mailto:UID:[email-masked]"=20
  =
target=3D_blank>UID:[email-masked]</A><BR>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  DTSTAMP:20080124T160825Z<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  SUMMARY:Dinner with =
my&nbsp;mum<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  DURATION:PT4H<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  BEGIN:VFREEBUSY<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A=20
  href=3D"mailto:UID:[email-masked]"=20
  =
target=3D_blank>UID:[email-masked]</A><BR>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  DTSTAMP:20080124T160825Z<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  =
FREEBUSY;FBTYPE=3DFREE:20080124T170000Z/20080125T000000Z<BR>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  END:VFREEBUSY<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  END:VIMPRECISEEVENT</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>If I look at this inside a client =
that=20
  supports&nbsp;<FONT face=3D"Times New Roman" =
size=3D3>VIMPRECISEEVENT</FONT> then=20
  perhaps it'll show it with appropriate annotation, but then when I =
view it in=20
  a client that doesn't support it I'll see absolutely nothing at all, =
implying=20
  that my evening is free.&nbsp; </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>I expected </FONT><FONT face=3DArial=20
  size=3D2>imprecise events to be&nbsp;specified by some modifier on the =

  DTSTART/DTEND properties.&nbsp; ie something like this (which also =
allows me=20
  to say it ends at midnight):</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  BEGIN:VIMPRECISEEVENT<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =

  href=3D"mailto:UID:[email-masked]"=20
  =
target=3D_blank>UID:[email-masked]</A><BR>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  DTSTAMP:20080124T160825Z<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  SUMMARY:Dinner with =
my&nbsp;mum<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  DURATION:PT4H</DIV>
  =
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DTSTART;RANGE=3D3H:2=
0080124170000Z</DIV>
  =
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DTEND:20081225000000=
Z<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  END:VIMPRECISEEVENT</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Now when I look at this in a client =
that doesn't=20
  understand the RANGE parameter on DTSTART, it'll show up as busy from=20
  5pm-12pm, and in a client that does, it can show a "fuzzy" start from =
5pm-8pm,=20
  and then definately busy up until 12pm.&nbsp; </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>A freebusy lookup could also then =
return=20
  meaningful data from both clients, whereas you've specified that <FONT =

  face=3D"Times New Roman" size=3D3>VIMPRECISEEVENT</FONT>&nbsp;is =
invisible to free=20
  busy lookups.&nbsp;&nbsp;The one that didn't support RANGE for=20
  DTSTART&nbsp;might return busy from 8-12, while the other could=20
  return:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"=20
  size=3D3>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  BEGIN:VFREEBUSY<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A=20
  href=3D"mailto:UID:[email-masked]"=20
  =
target=3D_blank>UID:[email-masked]</A><BR>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  DTSTAMP:20080124T160825Z<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  =
FREEBUSY;FBTYPE=3DBUSY-TENTATIVE:20080124T170000Z/20080124T200000Z<BR>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
FREEBUSY;FBTYPE=3DBUSY:20080124T200000Z/20080125T000000Z<BR>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  END:VFREEBUSY</FONT><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Admittedly adding a RANGE parameter =
to DTSTART=20
  and DTEND would not be as flexibly as specifying a duration and a list =
of=20
  constraints by means of free/busy, but it has the advantage of being =
far=20
  easier to apply to an existing iCalendar parser, rather than having to =
deal=20
  with an entirely new iCalendar component, so I think it might get a=20
  substantially bigger uptake.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>WRT to an event that specifies a =
medical=20
  appointment that occurs within&nbsp;one of several time periods (the =
second=20
  example in the spec), that could then be implemented&nbsp;either by =
means of=20
  STATUS:TENTATIVE on an appointment with an RRULE, or else by using =
<FONT=20
  size=3D3>VALTERNATIVEEVENTS.</FONT></FONT></DIV>
  <DIV><SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN><A=20
  =
name=3D117c2dc35508f571_117acfd71130c051_section-3.2><B>3.2</B></A><B>.&n=
bsp;=20
  Alternative Events Component</B></SPAN><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>In the interests of parser re-use, =
rather than=20
  specifying the default event properties in the&nbsp;<FONT=20
  size=3D3>alternativeeventsprop&nbsp;</FONT><FONT size=3D2>and then =
overridden in=20
  the <FONT size=3D3>*eventc</FONT>&nbsp;I'd be inclined to specify them =
by means=20
  of a "master event" section, of type eventc.&nbsp; Then if some new =
event=20
  property comes out, only the parser for eventc needs to be updated, =
rather=20
  than&nbsp;also the alternativeeventsprop collection.&nbsp; One=20
  slight&nbsp;problem is that for a vevent to be valid, it must have a =
dtstart,=20
  so&nbsp;I'd suggest we just refer to one of our alternative events as =
our=20
  "master event" that contains default properties.&nbsp;The example =
would become=20
  something like:</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BEGIN:VALTERNATIVEEVENTS</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"=20
  size=3D3>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A=20
  href=3D"mailto:UID:[email-masked]"=20
  =
target=3D_blank>UID:[email-masked]</A><BR>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=20
  DTSTAMP:20071005T133225Z</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"=20
  size=3D3>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A=20
  href=3D"mailto:DEFAULTPROPERTIES:[email-masked]" =

  =
target=3D_blank>DEFAULTPROPERTIES:[email-masked]</A=
><BR></FONT></FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BEGIN:VEVENT<BR>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  <A href=3D"mailto:UID:[email-masked]"=20
  =
target=3D_blank>UID:[email-masked]</A><BR>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
  DTSTAMP:20071005T133225Z<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  DTSTART:20071005T133225Z<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SUMMARY:Quick=20
  interop test<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; COMMENT:Trying the =
options that=20
  seem most likely to be accepted...</DIV>
  <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;END:VEVENT</DIV>
  <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  BEGIN:VEVENT<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A=20
  href=3D"mailto:UID:[email-masked]"=20
  =
target=3D_blank>UID:[email-masked]</A><BR>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
  DTSTAMP:20071005T133225Z<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  DTSTART:20080406T090000Z<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  DTEND:20080405T120000Z<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  RANK:100<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; COMMENT:It would be perfect =
if we=20
  could meet at that same time!<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  END:VEVENT<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
BEGIN:VIMPRECISEEVENT<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;..etc...<BR>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  END:VIMPRECISEEVENT<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  END:VALTERNATIVEEVENTS<BR></DIV>
  <DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial><SPAN><A=20
  =
name=3D117c2dc35508f571_117acfd71130c051_section-3.3><B>3.3</B></A><B>/3.=
4/3.5&nbsp;=20
  Minimum/Maximum Granularity/Rank Component =
Property</B></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>I think these are icing that I'd be =
inclined to=20
  ignore in an initial implementation.&nbsp; Even writing the gui and =
trying to=20
  communicate the concepts would be challenging.&nbsp; I'm also not sure =
why=20
  it's worth saying that Rank is defined as a %.&nbsp; Why not just an =
unsigned=20
  number?&nbsp; Then if you want to communicate it as a % you can =
evaluate the=20
  max/min Rank, and convert to a %.&nbsp; I'm sure 100 levels is plenty, =
but for=20
  the sake of writing a specification, I don't see why you couldn't just =
say=20
  it's an arbitrary number.&nbsp; It would be very annoying to find you =
needed=20
  more levels, but the standard didn't permit it.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Cheers</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial=20
size=3D2>Nigel</FONT></DIV></DIV></BLOCKQUOTE></DIV><BR></BODY></HTML>

------=_NextPart_000_00BF_01C862B4.AAC71BF0--

Date: Tue, 29 Jan 2008 21:38:12 -0300
From: "=?ISO-8859-1?Q?F=E1bio_Henrique_da_Silva?=" <[email-masked]>
To: "Nigel Swinson" <[email-masked]>
Subject: Re: [Ietf-calsify] Imprecise and alternative events for iCalendar andiTIP
Cc: [email-masked]

------=_Part_16649_5123350.1201653492421
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Dear Nigel,

Thanks for the comments! Yes, I think that, even with the difficulties
presented on the appendix of the draft, we should look for solutions
preserving backward compatibility. It would be nice to hear some opinions
about these alternative design solutions you proposed =3Do)

I would only point that, apart from the discussion on the number of levels
(0-100 is only an initial hint based on PERCENT-COMPLETE), the concept of
rank is relevant, since some event descriptions and time ranges must be
marked as more appropriate/desired/likely to be scheduled/... than others.

But the primary purpose of the draft is that: to start a discussion on how
to give more flexibility to iCalendar in a standard way, pointing that such
mechanisms would be really useful for scheduling negotiation.

Cheers,

F=E1bio.

On Jan 24, 2008 3:09 PM, Nigel Swinson <[email-masked]> wrote:

>         Title           : Imprecise and alternative events for iCalendar
> and iTIP
>        Author(s)       : F. Silva, R. Drummond
>        Filename        : draft-silva-events-01.txt
>        Pages           : 55
>        Date            : 2007-12-21
>
> This has long been something that has annoyed me about digital
> calendaring, so I'm delighted to see that this work is proceeding :o)  I'=
ve
> finally found the time to read the document, and have the following
> comments.
>
> *3.1**.  Imprecise Event Component*
> Given that calendars are being shared so much between so many clients, I
> feel uneasy about the lack of backward compatibility expressed in the
> document as it stands.  Suppose I was to arrange with my mum to have
> dinner tonight, but we hadn't yet agreed a time.  I would then "guess" th=
an
> the meal would start somewhere between 5pm and 8pm and last until midnigh=
t.
> To begin with I don't think I can say the event will last until midnight,
> regardless of it's start time, so lets assume I say it is going to last 4
> hours.  Writing this as a VIMPRECISEEVENT I think I'd have to write this
> as:
>
>         BEGIN:VIMPRECISEEVENT
>         UID:[email-masked]
>         DTSTAMP:20080124T160825Z
>         SUMMARY:Dinner with my mum
>         DURATION:PT4H
>         BEGIN:VFREEBUSY
>         UID:[email-masked]
>         DTSTAMP:20080124T160825Z
>         FREEBUSY;FBTYPE=3DFREE:20080124T170000Z/20080125T000000Z
>         END:VFREEBUSY
>         END:VIMPRECISEEVENT
>
> If I look at this inside a client that supports VIMPRECISEEVENT then
> perhaps it'll show it with appropriate annotation, but then when I view i=
t
> in a client that doesn't support it I'll see absolutely nothing at all,
> implying that my evening is free.
>
> I expected imprecise events to be specified by some modifier on the
> DTSTART/DTEND properties.  ie something like this (which also allows me t=
o
> say it ends at midnight):
>
>         BEGIN:VIMPRECISEEVENT
>         UID:[email-masked]
>         DTSTAMP:20080124T160825Z
>         SUMMARY:Dinner with my mum
>         DURATION:PT4H
>         DTSTART;RANGE=3D3H:20080124170000Z
>         DTEND:20081225000000Z
>         END:VIMPRECISEEVENT
>
> Now when I look at this in a client that doesn't understand the RANGE
> parameter on DTSTART, it'll show up as busy from 5pm-12pm, and in a clien=
t
> that does, it can show a "fuzzy" start from 5pm-8pm, and then definately
> busy up until 12pm.
>
> A freebusy lookup could also then return meaningful data from both
> clients, whereas you've specified that VIMPRECISEEVENT is invisible to
> free busy lookups.  The one that didn't support RANGE for DTSTART might
> return busy from 8-12, while the other could return:
>
>         BEGIN:VFREEBUSY
>         UID:[email-masked]
>         DTSTAMP:20080124T160825Z
>         FREEBUSY;FBTYPE=3DBUSY-TENTATIVE:20080124T170000Z/20080124T200000=
Z
>         FREEBUSY;FBTYPE=3DBUSY:20080124T200000Z/20080125T000000Z
>         END:VFREEBUSY
> Admittedly adding a RANGE parameter to DTSTART and DTEND would not be as
> flexibly as specifying a duration and a list of constraints by means of
> free/busy, but it has the advantage of being far easier to apply to an
> existing iCalendar parser, rather than having to deal with an entirely ne=
w
> iCalendar component, so I think it might get a substantially bigger uptak=
e.
>
> WRT to an event that specifies a medical appointment that occurs
> within one of several time periods (the second example in the spec), that
> could then be implemented either by means of STATUS:TENTATIVE on an
> appointment with an RRULE, or else by using VALTERNATIVEEVENTS.
>
> *3.2**.  Alternative Events Component*
> In the interests of parser re-use, rather than specifying the default
> event properties in the alternativeeventsprop and then overridden in the
> *eventc I'd be inclined to specify them by means of a "master event"
> section, of type eventc.  Then if some new event property comes out, only
> the parser for eventc needs to be updated, rather than also the
> alternativeeventsprop collection.  One slight problem is that for a veven=
t
> to be valid, it must have a dtstart, so I'd suggest we just refer to one =
of
> our alternative events as our "master event" that contains default
> properties. The example would become something like:
>
>       BEGIN:VALTERNATIVEEVENTS
>       UID:[email-masked]
>       DTSTAMP:20071005T133225Z
>       DEFAULTPROPERTIES:[email-masked]
>       BEGIN:VEVENT
>       UID:[email-masked]
>       DTSTAMP:20071005T133225Z
>       DTSTART:20071005T133225Z
>       SUMMARY:Quick interop test
>       COMMENT:Trying the options that seem most likely to be accepted...
>       END:VEVENT
>       BEGIN:VEVENT
>       UID:[email-masked]
>       DTSTAMP:20071005T133225Z
>       DTSTART:20080406T090000Z
>       DTEND:20080405T120000Z
>       RANK:100
>       COMMENT:It would be perfect if we could meet at that same time!
>       END:VEVENT
>       BEGIN:VIMPRECISEEVENT
>       ..etc...
>       END:VIMPRECISEEVENT
>       END:VALTERNATIVEEVENTS
>
> *3.3**/3.4/3.5  Minimum/Maximum Granularity/Rank Component Property*
>
> I think these are icing that I'd be inclined to ignore in an initial
> implementation.  Even writing the gui and trying to communicate the conce=
pts
> would be challenging.  I'm also not sure why it's worth saying that Rank =
is
> defined as a %.  Why not just an unsigned number?  Then if you want to
> communicate it as a % you can evaluate the max/min Rank, and convert to a
> %.  I'm sure 100 levels is plenty, but for the sake of writing a
> specification, I don't see why you couldn't just say it's an arbitrary
> number.  It would be very annoying to find you needed more levels, but th=
e
> standard didn't permit it.
>
> Cheers
>
> Nigel
>

------=_Part_16649_5123350.1201653492421
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Dear Nigel,<br><br>Thanks for the comments! Yes, I think that, even with th=
e difficulties presented on the appendix of the draft, we should look for s=
olutions preserving backward compatibility. It would be nice to hear some o=
pinions about these alternative design solutions you proposed =3Do)<br>
<br>I would only point that, apart from the discussion on the number of lev=
els (0-100 is only an initial hint based on PERCENT-COMPLETE), the concept =
of rank is relevant, since some event descriptions and time ranges must be =
marked as more appropriate/desired/likely to be scheduled/... than others.<=
br>
<br>But the primary purpose of the draft is that: to start a discussion on =
how to give more flexibility to iCalendar in a standard way, pointing that =
such mechanisms would be really useful for scheduling negotiation.<br><br>
Cheers,<br>
<br>F=E1bio.<br><br><div class=3D"gmail_quote">On Jan 24, 2008 3:09 PM, Nig=
el Swinson &lt;<a href=3D"mailto:[email-masked]" target=3D"_bla=
nk">[email-masked]</a>&gt; wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt=
 0pt 0.8ex; padding-left: 1ex;">

<div bgcolor=3D"#ffffff"><div>
<blockquote style=3D"border-left: 2px solid rgb(0, 0, 0); padding-right: 0p=
x; padding-left: 5px; margin-left: 5px; margin-right: 0px;">&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;Title=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : Imprecise and alternative events for=
=20
  iCalendar and iTIP<br>&nbsp; &nbsp; &nbsp; &nbsp;Author(s) &nbsp; &nbsp;=
=20
  &nbsp; : F. Silva, R. Drummond<br>&nbsp; &nbsp; &nbsp; &nbsp;Filename &nb=
sp;=20
  &nbsp; &nbsp; &nbsp;: draft-silva-events-01.txt<br>&nbsp; &nbsp; &nbsp;=
=20
  &nbsp;Pages &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : 55 <br>&nbsp; &nbsp; &nb=
sp;=20
  &nbsp;Date &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;: 2007-12-21</blockqu=
ote></div>
<div><font face=3D"Arial" size=3D"2">This has long been something that has =
annoyed me=20
about digital calendaring, so I&#39;m delighted to see that this work is pr=
oceeding=20
:o)&nbsp; I&#39;ve finally found the time to read the document, and have th=
e=20
following comments.</font></div>
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div>
<div><span><a name=3D"117c2dc35508f571_117acfd71130c051_section-3.1"><b>3.1=
</b></a><b>.&nbsp;=20
Imprecise Event Component</b></span><br></div>
<div><font face=3D"Arial" size=3D"2">Given that calendars are being shared =
so much=20
between so many clients, I feel uneasy about the lack of backward compatibi=
lity=20
expressed in the document as it stands.&nbsp; Suppose I was to arrange with=
 my=20
mum to have dinner&nbsp;tonight, but we hadn&#39;t yet agreed a time.&nbsp;=
 I would=20
then &quot;guess&quot; than the meal would start somewhere between 5pm and =
8pm and last=20
until midnight.&nbsp; To begin with I don&#39;t think I can say the&nbsp;ev=
ent will=20
last until midnight, regardless of it&#39;s start time, so lets assume I sa=
y it is=20
going to last 4 hours.&nbsp; Writing this as a <font size=3D"3">VIMPRECISEE=
VENT=20
</font></font><font face=3D"Arial" size=3D"2">I think I&#39;d have to write=
 this=20
as:</font></div>
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
BEGIN:VIMPRECISEEVENT<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<a href=3D"mailto:UID:[email-masked]" target=3D"_blank"=
>UID:[email-masked]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
DTSTAMP:20080124T160825Z<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
SUMMARY:Dinner with my&nbsp;mum<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
DURATION:PT4H<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
BEGIN:VFREEBUSY<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<a href=3D"mailto:UID:[email-masked]" target=3D"_blank=
">UID:[email-masked]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
DTSTAMP:20080124T160825Z<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
FREEBUSY;FBTYPE=3DFREE:20080124T170000Z/20080125T000000Z<br>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
END:VFREEBUSY<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
END:VIMPRECISEEVENT</div>
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div>
<div><font face=3D"Arial" size=3D"2">If I look at this inside a client that=
=20
supports&nbsp;<font face=3D"Times New Roman" size=3D"3">VIMPRECISEEVENT</fo=
nt> then=20
perhaps it&#39;ll show it with appropriate annotation, but then when I view=
 it in a=20
client that doesn&#39;t support it I&#39;ll see absolutely nothing at all, =
implying that=20
my evening is free.&nbsp; </font></div>
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div>
<div><font face=3D"Arial" size=3D"2">I expected </font><font face=3D"Arial"=
 size=3D"2">imprecise=20
events to be&nbsp;specified by some modifier on the DTSTART/DTEND=20
properties.&nbsp; ie something like this (which also allows me to say it en=
ds at=20
midnight):</font></div>
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
BEGIN:VIMPRECISEEVENT<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<a href=3D"mailto:UID:[email-masked]" target=3D"_blank"=
>UID:[email-masked]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
DTSTAMP:20080124T160825Z<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
SUMMARY:Dinner with my&nbsp;mum<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
DURATION:PT4H</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DTSTART;RANGE=3D3H:200=
80124170000Z</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DTEND:20081225000000Z<=
br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
END:VIMPRECISEEVENT</div>
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div>
<div><font face=3D"Arial" size=3D"2">Now when I look at this in a client th=
at doesn&#39;t=20
understand the RANGE parameter on DTSTART, it&#39;ll show up as busy from 5=
pm-12pm,=20
and in a client that does, it can show a &quot;fuzzy&quot; start from 5pm-8=
pm, and then=20
definately busy up until 12pm.&nbsp; </font></div>
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div>
<div><font face=3D"Arial" size=3D"2">A freebusy lookup could also then retu=
rn meaningful=20
data from both clients, whereas you&#39;ve specified that <font face=3D"Tim=
es New Roman" size=3D"3">VIMPRECISEEVENT</font>&nbsp;is invisible to free=
=20
busy lookups.&nbsp;&nbsp;The one that didn&#39;t support RANGE for=20
DTSTART&nbsp;might return busy from 8-12, while the other could=20
return:</font></div>
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div>
<div><font face=3D"Arial" size=3D"2"><font face=3D"Times New Roman" size=3D=
"3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
BEGIN:VFREEBUSY<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<a href=3D"mailto:UID:[email-masked]" target=3D"_blank=
">UID:[email-masked]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
DTSTAMP:20080124T160825Z<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
FREEBUSY;FBTYPE=3DBUSY-TENTATIVE:20080124T170000Z/20080124T200000Z<br>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
FREEBUSY;FBTYPE=3DBUSY:20080124T200000Z/20080125T000000Z<br>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
END:VFREEBUSY</font><br></font></div>
<div><font face=3D"Arial" size=3D"2">Admittedly adding a RANGE parameter to=
 DTSTART and=20
DTEND would not be as flexibly as specifying a duration and a list of=20
constraints by means of free/busy, but it has the advantage of being far ea=
sier=20
to apply to an existing iCalendar parser, rather than having to deal with a=
n=20
entirely new iCalendar component, so I think it might get a substantially b=
igger=20
uptake.</font></div>
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div>
<div><font face=3D"Arial" size=3D"2">WRT to an event that specifies a medic=
al=20
appointment that occurs within&nbsp;one of several time periods (the second=
=20
example in the spec), that could then be implemented&nbsp;either by means o=
f=20
STATUS:TENTATIVE on an appointment with an RRULE, or else by using <font si=
ze=3D"3">VALTERNATIVEEVENTS.</font></font></div>
<div><span></span>&nbsp;</div>
<div><span><a name=3D"117c2dc35508f571_117acfd71130c051_section-3.2"><b>3.2=
</b></a><b>.&nbsp;=20
Alternative Events Component</b></span><br></div>
<div><font face=3D"Arial" size=3D"2">In the interests of parser re-use, rat=
her than=20
specifying the default event properties in the&nbsp;<font size=3D"3">altern=
ativeeventsprop&nbsp;</font><font size=3D"2">and then overridden in the=20
<font size=3D"3">*eventc</font>&nbsp;I&#39;d be inclined to specify them by=
 means of a=20
&quot;master event&quot; section, of type eventc.&nbsp; Then if some new ev=
ent property=20
comes out, only the parser for eventc needs to be updated, rather than&nbsp=
;also=20
the alternativeeventsprop collection.&nbsp; One slight&nbsp;problem is that=
 for=20
a vevent to be valid, it must have a dtstart, so&nbsp;I&#39;d suggest we ju=
st refer=20
to one of our alternative events as our &quot;master event&quot; that conta=
ins default=20
properties.&nbsp;The example would become something like:</font></font></di=
v>
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BEGIN:VALTERNATIVEEVENTS</div>
<div><font face=3D"Arial" size=3D"2"><font face=3D"Times New Roman" size=3D=
"3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<a href=3D"mailto:UID:[email-masked]" target=3D"_blank"=
>UID:[email-masked]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
DTSTAMP:20071005T133225Z</font></font></div>
<div><font face=3D"Arial" size=3D"2"><font face=3D"Times New Roman" size=3D=
"3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"mailto:DEFAULTPROPERTIES=
:[email-masked]" target=3D"_blank">DEFAULTPROPERTIES:=
[email-masked]</a><br>

</font></font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BEGIN:VEVENT<br>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
<a href=3D"mailto:UID:[email-masked]" target=3D"_blan=
k">UID:[email-masked]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
DTSTAMP:20071005T133225Z<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DTSTART:20071005T133225Z<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SUMMARY:Quick in=
terop=20
test<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; COMMENT:Trying the options that seem=
 most=20
likely to be accepted...</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;END:VEVENT</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
BEGIN:VEVENT<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<a href=3D"mailto:UID:[email-masked]" target=3D"_blan=
k">UID:[email-masked]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
DTSTAMP:20071005T133225Z<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DTSTART:20080406T090000Z<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DTEND:20080405T120000Z<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
RANK:100<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; COMMENT:It would be perfect if w=
e=20
could meet at that same time!<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
END:VEVENT<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
BEGIN:VIMPRECISEEVENT<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;..etc...<br>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
END:VIMPRECISEEVENT<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
END:VALTERNATIVEEVENTS<br></div>
<div><font face=3D"Arial"></font>&nbsp;</div>
<div><font face=3D"Arial"><span><a name=3D"117c2dc35508f571_117acfd71130c05=
1_section-3.3"><b>3.3</b></a><b>/3.4/3.5&nbsp; Minimum/Maximum=20
Granularity/Rank Component Property</b></span></font></div>
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div>
<div><font face=3D"Arial" size=3D"2">I think these are icing that I&#39;d b=
e inclined to=20
ignore in an initial implementation.&nbsp; Even writing the gui and trying =
to=20
communicate the concepts would be challenging.&nbsp; I&#39;m also not sure =
why it&#39;s=20
worth saying that Rank is defined as a %.&nbsp; Why not just an unsigned=20
number?&nbsp; Then if you want to communicate it as a % you can evaluate th=
e=20
max/min Rank, and convert to a %.&nbsp; I&#39;m sure 100 levels is plenty, =
but for=20
the sake of writing a specification, I don&#39;t see why you couldn&#39;t j=
ust say it&#39;s=20
an arbitrary number.&nbsp; It would be very annoying to find you needed mor=
e=20
levels, but the standard didn&#39;t permit it.</font></div>
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div>
<div><font face=3D"Arial" size=3D"2">Cheers</font></div>
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div>
<div><font face=3D"Arial" size=3D"2">Nigel</font></div></div>
</blockquote></div><br>

------=_Part_16649_5123350.1201653492421--

From: "Darryl Champagne" <[email-masked]>
To: "'Tim Hare'" <[email-masked]>, <[email-masked]>
Subject: RE: [Ietf-calsify] RFC2445 latest IETF document?
Date: Mon, 28 Jan 2008 23:56:48 -0500

Hi,

dgc

-----Original Message-----

Thanks

Tim Hare

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Date: Mon, 28 Jan 2008 22:27:13 -0500
Subject: [Ietf-calsify] RFC2445 latest IETF document?

Thanks

Tim Hare

Date: Mon, 28 Jan 2008 19:09:12 -0800
To: [email-masked]
From: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] As long as we're talking about PARTSTAT...

john noerenberg

Date: Tue, 22 Jan 2008 12:56:18 -0800
To: Cyrus Daboo <[email-masked]>
From: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] As long as we're talking about PARTSTAT...
Cc: [email-masked]

john noerenberg

Date: Tue, 22 Jan 2008 10:30:21 -0800
To: Cyrus Daboo <[email-masked]>
From: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] As long as we're talking about PARTSTAT...
Cc: [email-masked]

-- 

john noerenberg

Date: Mon, 21 Jan 2008 21:38:17 -0500
From: Cyrus Daboo <[email-masked]>
To: John W Noerenberg II <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] As long as we're talking about PARTSTAT...

Hi John,

-- 
Cyrus Daboo

Date: Mon, 21 Jan 2008 16:38:39 -0800
To: <[email-masked]>
From: John W Noerenberg II <[email-masked]>
Subject: [Ietf-calsify] As long as we're talking about PARTSTAT...

john noerenberg

Date: Mon, 21 Jan 2008 16:20:57 -0800
To: Eliot Lear <[email-masked]>
From: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] Interpreting 2.1.5 Message Sequencing in rfc2446bis
Cc: [email-masked]

john noerenberg

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] Interpreting 2.1.5 Message Sequencing in rfc2446bis
Date: Sat, 19 Jan 2008 16:51:45 -0500

Tim Hare

-----Original Message-----

Hello John,

Eliot

Date: Sat, 19 Jan 2008 13:33:49 +0100
From: Eliot Lear <[email-masked]>
To: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] Interpreting 2.1.5 Message Sequencing in rfc2446bis
Cc: [email-masked]

Hello John,

Eliot

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] Interpreting 2.1.5 Message Sequencing in rfc2446bis
Date: Fri, 18 Jan 2008 21:27:31 -0500

Tim Hare

-----Original Message-----

2.1.5 3. says:

john noerenberg

Date: Fri, 18 Jan 2008 14:58:35 -0800
To: [email-masked]
From: John W Noerenberg II <[email-masked]>
Subject: [Ietf-calsify] Interpreting 2.1.5 Message Sequencing in rfc2446bis

2.1.5 3. says:

john noerenberg

Date: Thu, 17 Jan 2008 16:51:33 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue list for rfc2446bis closes on March 1!

Dear all,

In an effort to bring this group's efforts to a close the chairs would 
like to close the issues list for rfc2446bis.  The primary topic for the 
IETF meeting will be any open issues.  After March 1, only those issues 
that arise due to resolution of open issues will be entertained.

Thanks for your support,

For Aki, Eliot
Calsify co-chair

Date: Wed, 16 Jan 2008 13:18:48 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] reminder: Calsify call today, 9:30am US/New York.  Call information follows below

The agenda will be the changes Bernard proposed, as well as (hopefully) 
those that Cyrus will have proposed.

Eliot
*
Meeting ID:*              312147852
*Meeting Password:*       

*Global Access Numbers:*
*http://cisco.com/en/US/about/doing_business/conferencing/index.html*

   * US/Canada:*  +1.866.432.9903   * United Kingdom:*   +44.20.8824.0117
   * India:*      +91.80.4103.3979  * Germany:*          +49.619.6773.9002
   * Japan:*      +81.3.5763.9394   * China:*            +86.10.8515.5666

*TO ATTEND A WEB AND VOICE CONFERENCE*

*CISCO INTRANET ATTENDEES*
*Join the Web & Voice Conference**
1. Go to* http://meetingplaceinternal.cisco.com/join.asp?312147852*
2. Enter your* CEC User ID* &* Password* then click* OK*
- Accept any security warnings you receive and wait for the Meeting Room 
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference 
portion of the meeting

*EXTERNAL ATTENDEES* -* Outside the Cisco Intranet***
*Join the Web & Voice Conference**
1. Go to* http://meetingplace.cisco.com/join.asp?312147852*
2. Fill in the* My Name is* field then click* Attend Meeting*
- If you have a* CEC User ID*, click on the* Cisco icon*
- Accept any security warnings you receive and wait for the Meeting Room 
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference 
portion of the meeting
-* Note:* Guest users will see a link to the Global Access Numbers.

***If this is your first time attending a Web Conference, disable any 
pop-up blockers and visit* 
http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp* to 
test your web browser for compatibility with the Web Conference.

****Not all meetings are scheduled to allow external attendees into the 
Web Conference portion of the meeting, if the URL does not work, please 
follow the Voice only Conference instructions below to attend.

*TO ATTEND A VOICE ONLY CONFERENCE*
1. Dial into Cisco Unified MeetingPlace (view the Access Numbers or link 
above)
2. Press* 1* to attend the meeting
3. Follow the prompts to enter the Meeting ID* 312147852* and join the 
meeting

*SUPPORT*
*Information about this Conference:* Contact Eliot Lear, 41448787525
*Cisco IT Support Center:* Attend the Voice Conference and then press #0 
on your phone keypad

*GLOBAL ACCESS NUMBERS*

*COUNTRY            LOCATION           LOCAL NUMBER            TOLL 
FREE-FREEFONE*
*Algeria           * Algiers            +213.21.98.9047
*Argentina*          Buenos Aires       +54.11.4341.0101
*Australia*          All Locations      +86.16.0643
                   Canberra           +61.2.6216.0643         
                   Melbourne          +61.3.9659.4173
                   North Sydney       +61.2.8446.5260
*Austria*            Vienna             +43.12.4030.6022
*Azerbaijan        * Baku               +994.12.437.4829
*Belgium*            Brussels           +32.2.704.5072
*Bosnia &            *
*Herzegovina       * Sarajevo           +387.33.56.2898
*Brazil*             Brasilia           +55.613.424.0220
                   Rio de Janeiro     +55.21.2483.6302
                   Sao Paulo          +55.11.5508.6311
*Bulgaria*           Sofia              +359.2.937.5938
*Canada*             Calgary            +1.403.514.2435
                   Edmonton           +1.780.441.3715
                   Halifax            +1.902.474.0214
                   Kanata             +1.613.254.0005
                   Markham            +1.905.470.4810
                   Montreal           +1.514.847.6875
                   Ottawa             +1.613.788.7250
                   Quebec             +1.418.634.5645
                   Regina             +1.306.566.6410
                   Toronto            +1.416.306.7230
                   Vancouver          +1.604.647.2350
                   Winnipeg           +1.204.336.6610
*Chile*              Santiago           +56.2.431.4936
*China*              Beijing            +86.10.8515.5666
                   Chengdu            +86.28.8696.1333
                   Guangzhou          +86.20.8519.3333
                   Shanghai           +86.21.2302.4333
*Colombia*           Bogota             +57.1.325.6065
*Costa Rica        * San Jose           +506.201.3617
*Croatia*            Zagreb             +385.1.462.8908
*Czech Republic    * Prague             +420.22.143.5100
*Denmark*            Aabyhoj            +45.8.939.7131
                   Copenhagen         +45.3.958.5010
*Dominican Republic* Santo Domingo      +45.8.939.7131
*Egypt             * Cairo              +20.22.488.5377
*Estonia           * Tallinn            +372.6.67.5998
*Finland*            Espoo              +358.204.70.6227
*France*             Paris              +33.15.804.3116
*Germany*            Eschborn           +49.619.6773.9002
                   Hallbergmoos       +49.811.554.3016
*Greece*             Athens             +30.210.638.1303
*Hong Kong*          Hong Kong          +852.3406.1000
*Hungary*            Budapest           +36.1.225.4621
*India*              Bangalore          +91.80.4103.3979
                   Chennai                                    
+1.800.102.3979
                   Mumbai IL & FS     +91.22.4043.4030
                   New Delhi          +91.11.4261.1088
*Indonesia*          Jakarta            +62.21.7854.7476
*Ireland*            Dublin             +353.1.819.2717
*Israel*             Netanya            +972.9.892.7026
*Italy             * Milan              +39.039.629.5068
                   Rome               +39.06.5164.4006
*Japan*              Tokyo Akasaka      +81.3.5763.9394         
+0120.312271
*Kazakhstan*         Almaty             +7.327.244.2198
*Korea*              Seoul Asem         +82.2.3429.8102
*Latvia*                                Please see Finland
                                      Number
*Lebanon*            Beirut             +961.1.97.7011
*Malaysia*           Kuala Lumpur       +60.3.2081.1515
                   Penang             +60.4.631.5125
*Mexico*             Mexico City        +52.55.5267.1800
                   Monterrey          +52.81.8221.2462
                   Guadalajara        +52.33.3770.1206
*Morocco           * Casablanca         +212.2.242.4088
*Netherlands  *      Amsterdam          +31.20.357.1487
*New Zealand*        Auckland           +64.9.355.1968
                   Wellington         +64.4.496.5554
*Nigeria*            Lagos              +234.1.462.1048
*Norway*             Oslo               +47.23.27.3647
*Pakistan*           Islamabad          +92.51.209.7994
*Peru  *             Lima               +51.1.215.5101
*Philippines  *      Makati (Manila)    +63.2.750.5886
*Poland*             Warsaw             +48.22.572.2615
*Portugal*           Lisbon             +351.21.446.8756
*Puerto Rico*        San Juan           +1.787.620.1865
*Romania*            Bucharest          +40.21.302.3511
*Russia*             Moscow             +7.495.230.5612
*Saudi Arabia*       Dhahran            +966.3.865.7998
                   Jeddah             +966.2.653.6555
                   Riyadh             +966.1.218.2666
*Serbia*             Belgrade           +381.11.209.2098
*Singapore*          Singapore Capital  +65.6317.7088
*Slovakia*           Bratislava         +421.2.5825.5309
*Slovenia*           Ljubljana          +386.1.582.3158
*South Africa*       Cape Town          +27.21.413.4502
                   Johannesburg       +27.11.267.1011
                   Pretoria           +27.12.844.7401
*Spain*              Barcelona          +34.93.393.4037
                   Madrid             +34.91.201.2149
*Sweden*             Gothenburg         +46.31.63.4409
                   Stockholm          +46.8.685.9035
*Switzerland*        Glattzentrum       +41.44.878.7335
*Taiwan*             Taipei             +886.2.8758.7088
*Thailand*           Bangkok            +66.2.263.7008
*Turkey*             Istanbul           +90.212.335.0208
*Ukraine*            Kiev               +380.44.391.3698
*United Arab       *              
*Emirates(UAE)     * Dubai              +971.4.390.7840
*United Kingdom*     Bedfont Lakes      +44.20.8824.0117
                   Edinburgh          +44.131.561.3643
                   London City        +44.20.7496.3743
*United States*      East               +1.919.392.3330        
+1.866.349.3520
                   West               +1.408.525.6800        
+1.866.432.9903
*Venezuela*          Caracas            +58.212.902.0210
*Vietnam*            Ho Chi Minh        +84.8.823.3418
                   City (Saigon)
                   Hanoi              +84.4.974.6250

Date: Thu, 10 Jan 2008 22:01:09 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Issue 48: Section 4.2.13 Recurrence Identifier Range

Back in October 2006, we decided to deprecate the RANGE parameter
from iCalendar.  See:

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-October/001239.html
http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue48

As we found out, it is hard to do without RANGE=THISANDFUTURE
with unbounded recurring calendar components when the Organizer
wants to modify all future instances, or when an Attendee wants
to modify his participation status to all future instances.

Here's a proposal along the lines of what was discussed at the
last IETF meeting in Vancouver.

- Revert the change to deprecate the RANGE parameter.

- Only the THISANDPRIOR value would be deprecated.

- Clarify that THISANDFUTURE is based on RECURRENCE-ID
   values and not the current value of DTSTART.

- Clarify that exception components have precedence
   over THISANDFUTURE.

- Clarify that when the recurrence instance specified with
   RANGE=THISANDFUTURE is rescheduled, that all future recurrence
   instances ends up being rescheduled "the same way". For
   instance, if the recurrence instance specified with
   RANGE=THISANDFUTURE is rescheduled to start 2 hours later
   then all future instances will also be rescheduled to start
   2 hours later. Similarly, if the duration of the recurrence
   instance specified with RANGE=THISANDFUTURE is modified then
   all future recurrence instances should be changed to have this
   new duration.

   Obviously, there will be cases where this approach will not be
   sufficient to reschedule all future instances exactly like the
   end user wants. Let's take the case of a recurrence meeting
   scheduled to occur on Monday and Wednesday for ever. At some
   point the Organizer decides to reschedule all future Wednesday
   instances to occur on Thursday instead. With the approach
   mentioned above this is not possible, since all future
   instances (i.e., including the Monday instances) would end up
   being rescheduled to start 24 hours later (i.e., the Monday
   instances would be rescheduled on Tuesday). In such situations
   the calendar application should truncate the unbounded
   recurring calendar components and create a new unbounded
   recurring calendar components for the future instances.

Cheers,
Bernard

From: Tomas Hnetila <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] preliminary minutes
Date: Thu, 10 Jan 2008 18:09:41 +0100
Cc: [email-masked]

--Apple-Mail-1-486966204
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Hi Eliot,

We currently doesn't officially support counter/decline-counter  
methods exactly as it defined in RFC in Kerio MailServer, but our  
intention improve it to be in conformance with the RFC.
"Propose new time" function is supported by Microsoft Outlook and  
Windows Mobile (ActiveSync) devices.

This function is very useful for busy people who uses calendaring  
product often. I recommend to keep counter methode in RFC.

Tom

On Jan 3, 2008, at 3:04 PM, Eliot Lear wrote:

>
>   Issue #87
>    Eliot queried how many clients support counter/decline-counter,
>    and there seem to be at least some.  There was no consensus to
>    remove, and so the issue is rejected.

--Apple-Mail-1-486966204
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div>Hi Eliot,</div><div><br =
class=3D"webkit-block-placeholder"></div><div>We&nbsp;currently&nbsp;doesn=
't officially support =
counter/decline-counter&nbsp;methods&nbsp;exactly&nbsp;as it defined in =
RFC&nbsp;in Kerio MailServer, but our intention improve it to be in =
conformance with the RFC.</div><div>"Propose new time" function is =
supported by Microsoft Outlook and Windows Mobile (ActiveSync) =
devices.</div><div><br></div><div>This function is very useful for busy =
people who uses calendaring product often. I recommend to keep counter =
methode in RFC.</div><div><br></div><div>Tom</div><div><br =
class=3D"webkit-block-placeholder"></div><div><br></div><div><div>On Jan =
3, 2008, at 3:04 PM, Eliot Lear wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Monaco; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><br>&nbsp;&nbsp;Issue =
#87<br>&nbsp;&nbsp;&nbsp;Eliot queried how many clients support =
counter/decline-counter,<br>&nbsp;&nbsp;&nbsp;and there seem to be at =
least some. &nbsp;There was no consensus to<br>&nbsp;&nbsp;&nbsp;remove, =
and so the issue is =
rejected.</span></blockquote></div><br></body></html>=

--Apple-Mail-1-486966204--

Date: Thu, 10 Jan 2008 10:19:16 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] no quorum for yesterday's call

Dear all,

As yesterday's call was very small (4 people) we decided to put off any 
substantial discussions.  You can expect proposals from Bernard and 
Cyrus on issues relating to their drafts within the week.  These calls 
are meant to be weekly, and so we will have another one next Wednesday, 
9:30am America/New York.  I will put out an iCal invite sometime today.

Eliot

Date: Wed, 09 Jan 2008 15:29:06 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] reminder: calsify call now!!

This is a multi-part message in MIME format.
--------------040701020007000003030308
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

--------------040701020007000003030308
Content-Type: message/rfc822;
 name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Attached Message"

Date: Mon, 07 Jan 2008 13:29:44 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] reminder: phone call january 9,
	9:30am EST  / 3:30pm CET
Sender: [email-masked]

The agenda will be to go over remaining items in iTIP.  Here is the 
call-in information:

*Eliot Lear has invited you to a Cisco Unified MeetingPlace Conference*

*Date/Time:*               January 09, 2008 at 03:30PM Europe/Amsterdam
*Length:*                  70
*Frequency:*               This meeting is scheduled to occur every 
Wednesday for 6 weeks.
*Meeting ID:*              312147852
*Meeting Password:*       

*Global Access Numbers:*
*http://cisco.com/en/US/about/doing_business/conferencing/index.html*

   * US/Canada:*  +1.866.432.9903   * United Kingdom:*   +44.20.8824.0117
   * India:*      +91.80.4103.3979  * Germany:*          +49.619.6773.9002
   * Japan:*      +81.3.5763.9394   * China:*            +86.10.8515.5666

*TO ATTEND A WEB AND VOICE CONFERENCE*

*CISCO INTRANET ATTENDEES*
*Join the Web & Voice Conference**
1. Go to* http://meetingplaceinternal.cisco.com/join.asp?312147852*
2. Enter your* CEC User ID* &* Password* then click* OK*
- Accept any security warnings you receive and wait for the Meeting Room 
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference 
portion of the meeting

*EXTERNAL ATTENDEES* -* Outside the Cisco Intranet***
*Join the Web & Voice Conference**
1. Go to* http://meetingplace.cisco.com/join.asp?312147852*
2. Fill in the* My Name is* field then click* Attend Meeting*
- If you have a* CEC User ID*, click on the* Cisco icon*
- Accept any security warnings you receive and wait for the Meeting Room 
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference 
portion of the meeting
-* Note:* Guest users will see a link to the Global Access Numbers.

***If this is your first time attending a Web Conference, disable any 
pop-up blockers and visit* 
http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp* to 
test your web browser for compatibility with the Web Conference.

****Not all meetings are scheduled to allow external attendees into the 
Web Conference portion of the meeting, if the URL does not work, please 
follow the Voice only Conference instructions below to attend.

*TO ATTEND A VOICE ONLY CONFERENCE*
1. Dial into Cisco Unified MeetingPlace (view the Access Numbers or link 
above)
2. Press* 1* to attend the meeting
3. Follow the prompts to enter the Meeting ID* 312147852* and join the 
meeting

*SUPPORT*
*Information about this Conference:* Contact Eliot Lear, 41448787525
*Cisco IT Support Center:* Attend the Voice Conference and then press #0 
on your phone keypad

*GLOBAL ACCESS NUMBERS*

*COUNTRY            LOCATION           LOCAL NUMBER            TOLL 
FREE-FREEFONE*
*Algeria           * Algiers            +213.21.98.9047
*Argentina*          Buenos Aires       +54.11.4341.0101
*Australia*          All Locations      +86.16.0643
                   Canberra           +61.2.6216.0643         
                   Melbourne          +61.3.9659.4173
                   North Sydney       +61.2.8446.5260
*Austria*            Vienna             +43.12.4030.6022
*Azerbaijan        * Baku               +994.12.437.4829
*Belgium*            Brussels           +32.2.704.5072
*Bosnia &            *
*Herzegovina       * Sarajevo           +387.33.56.2898
*Brazil*             Brasilia           +55.613.424.0220
                   Rio de Janeiro     +55.21.2483.6302
                   Sao Paulo          +55.11.5508.6311
*Bulgaria*           Sofia              +359.2.937.5938
*Canada*             Calgary            +1.403.514.2435
                   Edmonton           +1.780.441.3715
                   Halifax            +1.902.474.0214
                   Kanata             +1.613.254.0005
                   Markham            +1.905.470.4810
                   Montreal           +1.514.847.6875
                   Ottawa             +1.613.788.7250
                   Quebec             +1.418.634.5645
                   Regina             +1.306.566.6410
                   Toronto            +1.416.306.7230
                   Vancouver          +1.604.647.2350
                   Winnipeg           +1.204.336.6610
*Chile*              Santiago           +56.2.431.4936
*China*              Beijing            +86.10.8515.5666
                   Chengdu            +86.28.8696.1333
                   Guangzhou          +86.20.8519.3333
                   Shanghai           +86.21.2302.4333
*Colombia*           Bogota             +57.1.325.6065
*Costa Rica        * San Jose           +506.201.3617
*Croatia*            Zagreb             +385.1.462.8908
*Czech Republic    * Prague             +420.22.143.5100
*Denmark*            Aabyhoj            +45.8.939.7131
                   Copenhagen         +45.3.958.5010
*Dominican Republic* Santo Domingo      +45.8.939.7131
*Egypt             * Cairo              +20.22.488.5377
*Estonia           * Tallinn            +372.6.67.5998
*Finland*            Espoo              +358.204.70.6227
*France*             Paris              +33.15.804.3116
*Germany*            Eschborn           +49.619.6773.9002
                   Hallbergmoos       +49.811.554.3016
*Greece*             Athens             +30.210.638.1303
*Hong Kong*          Hong Kong          +852.3406.1000
*Hungary*            Budapest           +36.1.225.4621
*India*              Bangalore          +91.80.4103.3979
                   Chennai                                    
+1.800.102.3979
                   Mumbai IL & FS     +91.22.4043.4030
                   New Delhi          +91.11.4261.1088
*Indonesia*          Jakarta            +62.21.7854.7476
*Ireland*            Dublin             +353.1.819.2717
*Israel*             Netanya            +972.9.892.7026
*Italy             * Milan              +39.039.629.5068
                   Rome               +39.06.5164.4006
*Japan*              Tokyo Akasaka      +81.3.5763.9394         
+0120.312271
*Kazakhstan*         Almaty             +7.327.244.2198
*Korea*              Seoul Asem         +82.2.3429.8102
*Latvia*                                Please see Finland
                                      Number
*Lebanon*            Beirut             +961.1.97.7011
*Malaysia*           Kuala Lumpur       +60.3.2081.1515
                   Penang             +60.4.631.5125
*Mexico*             Mexico City        +52.55.5267.1800
                   Monterrey          +52.81.8221.2462
                   Guadalajara        +52.33.3770.1206
*Morocco           * Casablanca         +212.2.242.4088
*Netherlands  *      Amsterdam          +31.20.357.1487
*New Zealand*        Auckland           +64.9.355.1968
                   Wellington         +64.4.496.5554
*Nigeria*            Lagos              +234.1.462.1048
*Norway*             Oslo               +47.23.27.3647
*Pakistan*           Islamabad          +92.51.209.7994
*Peru  *             Lima               +51.1.215.5101
*Philippines  *      Makati (Manila)    +63.2.750.5886
*Poland*             Warsaw             +48.22.572.2615
*Portugal*           Lisbon             +351.21.446.8756
*Puerto Rico*        San Juan           +1.787.620.1865
*Romania*            Bucharest          +40.21.302.3511
*Russia*             Moscow             +7.495.230.5612
*Saudi Arabia*       Dhahran            +966.3.865.7998
                   Jeddah             +966.2.653.6555
                   Riyadh             +966.1.218.2666
*Serbia*             Belgrade           +381.11.209.2098
*Singapore*          Singapore Capital  +65.6317.7088
*Slovakia*           Bratislava         +421.2.5825.5309
*Slovenia*           Ljubljana          +386.1.582.3158
*South Africa*       Cape Town          +27.21.413.4502
                   Johannesburg       +27.11.267.1011
                   Pretoria           +27.12.844.7401
*Spain*              Barcelona          +34.93.393.4037
                   Madrid             +34.91.201.2149
*Sweden*             Gothenburg         +46.31.63.4409
                   Stockholm          +46.8.685.9035
*Switzerland*        Glattzentrum       +41.44.878.7335
*Taiwan*             Taipei             +886.2.8758.7088
*Thailand*           Bangkok            +66.2.263.7008
*Turkey*             Istanbul           +90.212.335.0208
*Ukraine*            Kiev               +380.44.391.3698
*United Arab       *              
*Emirates(UAE)     * Dubai              +971.4.390.7840
*United Kingdom*     Bedfont Lakes      +44.20.8824.0117
                   Edinburgh          +44.131.561.3643
                   London City        +44.20.7496.3743
*United States*      East               +1.919.392.3330        
+1.866.349.3520
                   West               +1.408.525.6800        
+1.866.432.9903
*Venezuela*          Caracas            +58.212.902.0210
*Vietnam*            Ho Chi Minh        +84.8.823.3418
                   City (Saigon)
                   Hanoi              +84.4.974.6250

Microsoft Outlook Web Access: 
http://email.cisco.com/exchange/elear/Inbox/Meeting%3A%20IETF%20Calsify%20%7BMeeting%20ID%3A%20312147852%7D.EML?cmd=open

--------------040701020007000003030308--

Date: Mon, 07 Jan 2008 13:29:44 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] reminder: phone call january 9, 9:30am EST  / 3:30pm CET

The agenda will be to go over remaining items in iTIP.  Here is the 
call-in information:

*Eliot Lear has invited you to a Cisco Unified MeetingPlace Conference*

*Date/Time:*               January 09, 2008 at 03:30PM Europe/Amsterdam
*Length:*                  70
*Frequency:*               This meeting is scheduled to occur every 
Wednesday for 6 weeks.
*Meeting ID:*              312147852
*Meeting Password:*       

*Global Access Numbers:*
*http://cisco.com/en/US/about/doing_business/conferencing/index.html*

   * US/Canada:*  +1.866.432.9903   * United Kingdom:*   +44.20.8824.0117
   * India:*      +91.80.4103.3979  * Germany:*          +49.619.6773.9002
   * Japan:*      +81.3.5763.9394   * China:*            +86.10.8515.5666

*TO ATTEND A WEB AND VOICE CONFERENCE*

*CISCO INTRANET ATTENDEES*
*Join the Web & Voice Conference**
1. Go to* http://meetingplaceinternal.cisco.com/join.asp?312147852*
2. Enter your* CEC User ID* &* Password* then click* OK*
- Accept any security warnings you receive and wait for the Meeting Room 
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference 
portion of the meeting

*EXTERNAL ATTENDEES* -* Outside the Cisco Intranet***
*Join the Web & Voice Conference**
1. Go to* http://meetingplace.cisco.com/join.asp?312147852*
2. Fill in the* My Name is* field then click* Attend Meeting*
- If you have a* CEC User ID*, click on the* Cisco icon*
- Accept any security warnings you receive and wait for the Meeting Room 
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference 
portion of the meeting
-* Note:* Guest users will see a link to the Global Access Numbers.

***If this is your first time attending a Web Conference, disable any 
pop-up blockers and visit* 
http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp* to 
test your web browser for compatibility with the Web Conference.

****Not all meetings are scheduled to allow external attendees into the 
Web Conference portion of the meeting, if the URL does not work, please 
follow the Voice only Conference instructions below to attend.

*TO ATTEND A VOICE ONLY CONFERENCE*
1. Dial into Cisco Unified MeetingPlace (view the Access Numbers or link 
above)
2. Press* 1* to attend the meeting
3. Follow the prompts to enter the Meeting ID* 312147852* and join the 
meeting

*SUPPORT*
*Information about this Conference:* Contact Eliot Lear, 41448787525
*Cisco IT Support Center:* Attend the Voice Conference and then press #0 
on your phone keypad

*GLOBAL ACCESS NUMBERS*

*COUNTRY            LOCATION           LOCAL NUMBER            TOLL 
FREE-FREEFONE*
*Algeria           * Algiers            +213.21.98.9047
*Argentina*          Buenos Aires       +54.11.4341.0101
*Australia*          All Locations      +86.16.0643
                   Canberra           +61.2.6216.0643         
                   Melbourne          +61.3.9659.4173
                   North Sydney       +61.2.8446.5260
*Austria*            Vienna             +43.12.4030.6022
*Azerbaijan        * Baku               +994.12.437.4829
*Belgium*            Brussels           +32.2.704.5072
*Bosnia &            *
*Herzegovina       * Sarajevo           +387.33.56.2898
*Brazil*             Brasilia           +55.613.424.0220
                   Rio de Janeiro     +55.21.2483.6302
                   Sao Paulo          +55.11.5508.6311
*Bulgaria*           Sofia              +359.2.937.5938
*Canada*             Calgary            +1.403.514.2435
                   Edmonton           +1.780.441.3715
                   Halifax            +1.902.474.0214
                   Kanata             +1.613.254.0005
                   Markham            +1.905.470.4810
                   Montreal           +1.514.847.6875
                   Ottawa             +1.613.788.7250
                   Quebec             +1.418.634.5645
                   Regina             +1.306.566.6410
                   Toronto            +1.416.306.7230
                   Vancouver          +1.604.647.2350
                   Winnipeg           +1.204.336.6610
*Chile*              Santiago           +56.2.431.4936
*China*              Beijing            +86.10.8515.5666
                   Chengdu            +86.28.8696.1333
                   Guangzhou          +86.20.8519.3333
                   Shanghai           +86.21.2302.4333
*Colombia*           Bogota             +57.1.325.6065
*Costa Rica        * San Jose           +506.201.3617
*Croatia*            Zagreb             +385.1.462.8908
*Czech Republic    * Prague             +420.22.143.5100
*Denmark*            Aabyhoj            +45.8.939.7131
                   Copenhagen         +45.3.958.5010
*Dominican Republic* Santo Domingo      +45.8.939.7131
*Egypt             * Cairo              +20.22.488.5377
*Estonia           * Tallinn            +372.6.67.5998
*Finland*            Espoo              +358.204.70.6227
*France*             Paris              +33.15.804.3116
*Germany*            Eschborn           +49.619.6773.9002
                   Hallbergmoos       +49.811.554.3016
*Greece*             Athens             +30.210.638.1303
*Hong Kong*          Hong Kong          +852.3406.1000
*Hungary*            Budapest           +36.1.225.4621
*India*              Bangalore          +91.80.4103.3979
                   Chennai                                    
+1.800.102.3979
                   Mumbai IL & FS     +91.22.4043.4030
                   New Delhi          +91.11.4261.1088
*Indonesia*          Jakarta            +62.21.7854.7476
*Ireland*            Dublin             +353.1.819.2717
*Israel*             Netanya            +972.9.892.7026
*Italy             * Milan              +39.039.629.5068
                   Rome               +39.06.5164.4006
*Japan*              Tokyo Akasaka      +81.3.5763.9394         
+0120.312271
*Kazakhstan*         Almaty             +7.327.244.2198
*Korea*              Seoul Asem         +82.2.3429.8102
*Latvia*                                Please see Finland
                                      Number
*Lebanon*            Beirut             +961.1.97.7011
*Malaysia*           Kuala Lumpur       +60.3.2081.1515
                   Penang             +60.4.631.5125
*Mexico*             Mexico City        +52.55.5267.1800
                   Monterrey          +52.81.8221.2462
                   Guadalajara        +52.33.3770.1206
*Morocco           * Casablanca         +212.2.242.4088
*Netherlands  *      Amsterdam          +31.20.357.1487
*New Zealand*        Auckland           +64.9.355.1968
                   Wellington         +64.4.496.5554
*Nigeria*            Lagos              +234.1.462.1048
*Norway*             Oslo               +47.23.27.3647
*Pakistan*           Islamabad          +92.51.209.7994
*Peru  *             Lima               +51.1.215.5101
*Philippines  *      Makati (Manila)    +63.2.750.5886
*Poland*             Warsaw             +48.22.572.2615
*Portugal*           Lisbon             +351.21.446.8756
*Puerto Rico*        San Juan           +1.787.620.1865
*Romania*            Bucharest          +40.21.302.3511
*Russia*             Moscow             +7.495.230.5612
*Saudi Arabia*       Dhahran            +966.3.865.7998
                   Jeddah             +966.2.653.6555
                   Riyadh             +966.1.218.2666
*Serbia*             Belgrade           +381.11.209.2098
*Singapore*          Singapore Capital  +65.6317.7088
*Slovakia*           Bratislava         +421.2.5825.5309
*Slovenia*           Ljubljana          +386.1.582.3158
*South Africa*       Cape Town          +27.21.413.4502
                   Johannesburg       +27.11.267.1011
                   Pretoria           +27.12.844.7401
*Spain*              Barcelona          +34.93.393.4037
                   Madrid             +34.91.201.2149
*Sweden*             Gothenburg         +46.31.63.4409
                   Stockholm          +46.8.685.9035
*Switzerland*        Glattzentrum       +41.44.878.7335
*Taiwan*             Taipei             +886.2.8758.7088
*Thailand*           Bangkok            +66.2.263.7008
*Turkey*             Istanbul           +90.212.335.0208
*Ukraine*            Kiev               +380.44.391.3698
*United Arab       *              
*Emirates(UAE)     * Dubai              +971.4.390.7840
*United Kingdom*     Bedfont Lakes      +44.20.8824.0117
                   Edinburgh          +44.131.561.3643
                   London City        +44.20.7496.3743
*United States*      East               +1.919.392.3330        
+1.866.349.3520
                   West               +1.408.525.6800        
+1.866.432.9903
*Venezuela*          Caracas            +58.212.902.0210
*Vietnam*            Ho Chi Minh        +84.8.823.3418
                   City (Saigon)
                   Hanoi              +84.4.974.6250

Microsoft Outlook Web Access: 
http://email.cisco.com/exchange/elear/Inbox/Meeting%3A%20IETF%20Calsify%20%7BMeeting%20ID%3A%20312147852%7D.EML?cmd=open

Date: Thu, 03 Jan 2008 15:04:21 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] preliminary minutes

Thanks to Kurt for taking notes.  Please send comments to the list.

The Calsify WG met at the IETF meeting in Vancouver on December 3rd,
2007.  We started off with a status on rfc2445bis, which was that it
was in Shepherd review (that review is now completed).  The chairs
have recommitted to working with the authors to get these documents
done.  That will require interim phone calls.  We announced voice
meetings that will take place on Wednesdays, 9:30am, US/Eastern
starting next week.  If you wish to participate, please RSVP to Eliot.

Below are preliminary and rough minutes courtesy of Kurt.  Please
comment now about the discussion.  Note that Cyrus' slides are
available online at the IETF web site.

iTIP - Cyrus
  Provided summary of issues (no significant concerns to presentation
  unless noted).
  Issue #85
  This issue boils down to whether we can manage with unbounded
  ranges, and the answer today seemed to be that we cannot manage with
  unbounded ranges.  The working group discussed reintroducing
  "THISANDFUTURE".  Cyrus and Bernard are to propose text.

   Issue #86

    There was a lengthy discussion as to whether incrementing or not
    incrementing the SEQUENCE number meant anything from a UI
    perspective.  Cyrus pointed out that the client really needs to
    compare all details and make an appropriate determination.  The
    chairs note that there is not consensus at this point to remove
    SEQUENCE, however.  Pete Resnick pointed out that we need to
    separate "nagging the user" from notice to the organizer.
    Bernard pointed out that we need SEQUENCE to keep track of
    out-of-order messages.  Cyrus to offer proposal.

   Issue #87
    Eliot queried how many clients support counter/decline-counter,
    and there seem to be at least some.  There was no consensus to
    remove, and so the issue is rejected.

   Issue #90
        Eliot: defer until resolution of Issue#85
        More range= discussion.
    Eliot: no firm proposal, assume range is back, cyrus should
        propose text else close.

   Issue #95
    Issue seems to revolve around precedence (presently not specified)
    of error codes. Resolution: Cyrus will propose solution

   Issue #67
        Resolution: remove statement (no objections in room)

  Cyrus summarized removed xrole and removed references to procedural
  alarms in iTIP I-D, no concerns from room.

Bernard at mic regarding Issue 63
    Bernard: made proposal on list
    Eliot: there was an objection made on the list, no consensus at present.
    Cyrus: simple solution would be status quo.
    Bernard: will think about this hard before bringing it to the list.
    Eliot: status quo

Done @ 4:43