From Nigel.Swinson at rockliffe.com Wed Aug 1 08:46:04 2007
From: Nigel.Swinson at rockliffe.com (Nigel Swinson)
Date: Wed Aug 1 08:47:09 2007
Subject: "Re: [Ietf-calsify] Working Group Last
Call:draft-ietf-calsify-rfc2445bis-07.txt
References: <4693315B.6000008@cisco.com>
Message-ID: <00a501c7d453$1297a290$d201a8c0@nigelhome>
Below are my assorted notes based on reviewing the diff from v6 to v7. I
confess I haven't mustered the energy yet to do as Elliot sensibly suggests
and review the document as a whole, but I was still able to find a number of
editorial corrections most of which aren't too controvertial, but there's
some, specificially recurrence rule related that might be more contentious.
Version 7 contains numerous additions of this form:
"Applications MUST treat x-name and iana-token value they don't
recognized the same way as the XXXX value."
I don't think this is gramatically correct. I'd suggest:
"Applications MUST treat x-name and iana-token values they don't
recognize the same way as they would the XXXX value."
Or better still rely on the existing description of what the default value
is:
"Applications MUST ignore x-name and iana-token values they don't
recognize and revert to the default value for the parameter."
This comment applies to:
- 3.2. Property Parameters
- 3.2.3. Calendar User Type
- 3.2.9. Free/Busy Time Type
- 3.2.12. Participation Status
- 3.2.14. Relationship Type
- 3.2.15. Participation Role
- 3.2.19. Value Data Types
- 3.8.1.3. Classification
- 3.8.6.1. Action
3.3.10. Recurrence Rule
The UNTIL rule part defines a DATE or DATE-TIME value which bounds
the recurrence rule in an inclusive manner. If the value
specified by UNTIL is synchronized with the specified recurrence,
this DATE or DATE-TIME becomes the last instance of the
recurrence. The value of the UNTIL rule part MUST have the same
value type as the "DTSTART" property. Furthermore, if the
"DTSTART" property is specified as a date with local time, then
the UNTIL rule part MUST also be specified as a date with local
- time. Else, if the "DTSTART" property is specified as a date with
+ time. If the "DTSTART" property is specified as a date with
UTC time or a date with local time and time zone reference, then
the UNTIL rule part MUST be specified as a date with UTC time. In
the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
- rule part MUST always be specified as a date with UTC time. If
- specified as a DATE-TIME value, then it MUST be specified in a UTC
- time format. If not present, and the COUNT rule part is also not
+ rule part MUST always be specified as a date with UTC time, with the
+ "DTSTART" always represented as a date with local time. If the UNTIL
+ and COUNT rule parts are not
present, the "RRULE" is considered to repeat forever.
Below I've re-ordered the sentences in addition to changing one word. I
find changing from "the specific day" to "a specific day" helpful in warning
that 3MO in a yearly rule isn't necessarily "the 3rd Monday in the year" and
rather "a 3rd Monday in the year". Later we go on to describe in more
detail how to interpret "a 3rd Monday in the year".
Each BYDAY value can also be preceded by a positive (+n) or
negative (-n) integer. If present, this indicates the nth
- occurrence of the specific day within the MONTHLY or YEARLY
+ occurrence of a specific day within the MONTHLY or YEARLY
"RRULE". For example, within a MONTHLY rule, +1MO (or simply 1MO)
represents the first Monday within the month, whereas -1MO
- represents the last Monday of the month. If an integer modifier
+ represents the last Monday of the month. The
+ numeric value in a BYDAY rule part with the FREQ rule part set to
+ YEARLY corresponds to an offset within the month when the BYMONTH
+ rule part is present, and corresponds to an offset within the year
+ when the BYWEEKNO or BYMONTH rule parts are present.
+ If an integer modifier
is not present, it means all days of this type within the
specified frequency. For example, within a MONTHLY rule, MO
represents all Mondays within the month. The BYDAY rule part MUST
NOT be specified with a numeric value when the FREQ rule part is
not set to MONTHLY or YEARLY. Furthermore, the BYDAY rule part
MUST NOT be specified with a numeric value with the FREQ rule part
+ set to YEARLY when the BYWEEKNO rule part is specified.
- set to YEARLY when the BYWEEKNO rule part is specified. The
- numeric value in a BYDAY rule part with the FREQ rule part set to
- YEARLY corresponds to an offset within the month when the BYMONTH
- rule part is present, and corresponds to an offset within the year
- when the BYWEEKNO or BYMONTH rule parts are present.
The BYYEARDAY rule part specifies a COMMA character (US-ASCII
decimal 44) separated list of days of the year. Valid values are
1 to 366 or -366 to -1. For example, -1 represents the last day
of the year (December 31st) and -306 represents the 306th to the
last day of the year (March 1st). The BYYEARDAY rule part MUST
NOT be specified when the FREQ rule part is set to DAILY, WEEKLY,
- and MONTHLY.
+ or MONTHLY.
I think there's too many negatives in what was there:
The BYWEEKNO rule part specifies a COMMA character (US-ASCII
decimal 44) separated list of ordinals specifying weeks of the
year. Valid values are 1 to 53 or -53 to -1. This corresponds to
weeks according to week numbering as defined in [ISO.8601.2004].
A week is defined as a seven day period, starting on the day of
the week defined to be the week start (see WKST). Week number one
of the calendar year is the first week which contains at least
four (4) days in that calendar year. This rule part MUST NOT be
- used when the FREQ rule part is not set to YEARLY. For example, 3
+ used when the FREQ rule part is set to anything other than YEARLY.
+ For example, 3
represents the third week of the year.
WRT to the text below I think we should either:
- Say BYSETPOS is only valid with Weekly, Monthly, Yearly rules,
- Specify what the "interval" for daily, hourly, minutely, secondly means.
- Drop the new text, as I think the example is sufficient illustration.
- Change the example to illustrate what obscurity it was that lead to the
need for the new text.
My vote would be to drop some of the new text to become:
The BYSETPOS rule part specifies a COMMA character (US-ASCII
decimal 44) separated list of values which corresponds to the nth
occurrence within the set of recurrence instances specified by the
rule. BYSETPOS operates on a set of recurrence instances in one
- interval of the recurrence rule. For a WEEKLY rule, the interval
- is one week, for a MONTHLY rule, one month, and for a YEARLY rule,
- one year. Valid values are 1 to 366 or -366 to -1. It MUST only
+ interval of the recurrence rule.
+ Valid values are 1 to 366 or -366 to -1. It MUST only
be used in conjunction with another BYxxx rule part. For example
"the last work day of the month" could be represented as:
FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
Each BYSETPOS value can include a positive (+n) or negative (-n)
integer. If present, this indicates the nth occurrence of the
specific occurrence within the set of occurences specified by the
rule.
The phrase "special expand" is mentioned nowhere else in the document. I
think the concept was better expressed by my suggestion from the 29th May.
You merge the "Expand" cells in the Yearly/Monthly columns to illustrate
that each creates a set, and when taken together it's the union of the sets.
Also even with a numeric modifier on ByDay, it's still the case that
Monthly/Yearly + BYDAY will expand, and while it's true that numeric
modifiers on ByDay with yearly rules requires attention, I think it's
adequately dealt with in the paragraphs above on ByDay. So I'd make it:
- BYDAY has some special behaviour depending on the FREQ value and
- this is described in separate notes below the table.
+----------+--------+--------+-------+-------+------+-------+------+
| |SECONDLY|MINUTELY|HOURLY |DAILY |WEEKLY|MONTHLY|YEARLY|
+----------+--------+--------+-------+-------+------+-------+------+
- |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit |Expand|
- +----------+--------+--------+-------+-------+------+-------+------+
- |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A |Expand|
- +----------+--------+--------+-------+-------+------+-------+------+
- |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand|
- +----------+--------+--------+-------+-------+------+-------+------+
- |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A |Expand |Expand|
- +----------+--------+--------+-------+-------+------+-------+------+
- |BYDAY |Limit |Limit |Limit |Limit |Expand|Note 1 |Note 2|
- +----------+--------+--------+-------+-------+------+-------+------+
+ |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit | |
+ +----------+--------+--------+-------+-------+------+-------+ +
+ |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A | |
+ +----------+--------+--------+-------+-------+------+-------+ +
+ |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand|
+ +----------+--------+--------+-------+-------+------+-------+ +
+ |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A | | |
+ +----------+--------+--------+-------+-------+------+Expand + +
+ |BYDAY |Limit |Limit |Limit |Limit |Expand| | |
+ +----------+--------+--------+-------+-------+------+-------+------+
|BYHOUR |Limit |Limit |Limit |Expand |Expand|Expand |Expand|
+----------+--------+--------+-------+-------+------+-------+------+
|BYMINUTE |Limit |Limit |Expand |Expand |Expand|Expand |Expand|
+----------+--------+--------+-------+-------+------+-------+------+
|BYSECOND |Limit |Expand |Expand |Expand |Expand|Expand |Expand|
+----------+--------+--------+-------+-------+------+-------+------+
|BYSETPOS |Limit |Limit |Limit |Limit |Limit |Limit |Limit |
+----------+--------+--------+-------+-------+------+-------+------+
- Note 1: Limit if BYMONTHDAY is present, otherwise special expand
- for MONTHLY.
-
- Note 2: Limit if BYYEARDAY or BYMONTHDAY is present, otherwise
- special expand for WEEKLY if BYWEEKNO present, otherwise
- special expand for MONTHLY if BYMONTH present, otherwise
- special expand for YEARLY.
+ In YEARLY rules, BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY and BYDAY
work
+ together to expand the recurrence set. Each on their own will
specify
+ a range of valid instances, and when used in combination it is the
union
+ of all ranges that create the required recurrence set. So for
example
+ in a YEARLY rule BYDAY=MO will mean every Monday, and BYMONTHDAY=1
will
+ mean the first of every month, so when used together they mean the
first of
+ every month, but only when it's a Monday. It would not mean on the
first
+ of every month and also on every Monday. Likewise in MONTHLY rules,
+ BYMONTHDAY and BYDAY work together to expand the recurrence set.
3.6. Calendar Components
An iCalendar object MUST include the "PRODID" and "VERSION" calendar
properties. In addition, it MUST include at least one calendar
component. Special forms of iCalendar objects are possible to
publish just busy time (i.e., only a "VFREEBUSY" calendar component)
or time zone (i.e., only a "VTIMEZONE" calendar component)
information. In addition, a complex iCalendar object that is used to
capture a complete snapshot of the contents of a calendar is possible
(e.g., composite of many different calendar components). More
commonly, an iCalendar object will consist of just a single "VEVENT",
"VTODO" or "VJOURNAL" calendar component. Applications MUST ignore
- x-comp and iana-comp they don't recognized.
+ x-comp and iana-comp they don't recognize.
3.8.1.1. Attachment
Conformance: This property can be specified multiple times in a
"VEVENT", "VTODO", "VJOURNAL" or "VALARM" calendar component with
- the exception of AUDIO alarm which only allow this property to
+ the exception of AUDIO alarm which only allows this property to
occur once.
3.8.2.3. Date/Time Due
- Description: This property defines the date and time that a to-do is
+ Description: This property defines the date and time before which a
to-do is
expected to be completed. For cases where this property is
specified in a "VTODO" calendar component that also specifies a
"DTSTART" property, the value type of this property MUST be the
same as the "DTSTART" property, and the value of this property
MUST be later in time than the value of the "DTSTART" property.
Furthermore, this property MUST be specified as a date with local
time if and only if the "DTSTART" property is also specified as a
date with local time.
3.8.6.2. Repeat Count
- Description: This property defines the number of time an alarm
+ Description: This property defines the number of times an alarm
should be repeated after its initial trigger. If the alarm
triggers more than once, then this property MUST be specified
along with the "DURATION" property.
3.8.7.2. Date/Time Stamp
In the case of an iCalendar object that specifies a "METHOD"
- property, this property is different than the "CREATED" and "LAST-
+ property, this property is different to the "CREATED" and "LAST-
MODIFIED" properties. These two properties are used to specify
when the particular calendar data in the calendar store was
created and last modified. This is different than when the
iCalendar object representation of the calendar service
information was created or last modified.
Cheers,
Nigel
From lorenzo.detomasi at gmail.com Thu Aug 2 03:59:51 2007
From: lorenzo.detomasi at gmail.com (Lorenzo De Tomasi)
Date: Thu Aug 2 04:01:04 2007
Subject: [Ietf-calsify] Proposal of "Collections of events"
Message-ID: <5c2a5c380708020359v3046d7d8vd357a41a217ffa5e@mail.gmail.com>
I have read the draft and I think that it needs the support of
Collections of events.
Often, an event, especially when lasts more than one day, includes
other smaller events, contemporary or sequential, that can be
organized as chinese boxes.
Something like
?
?
or
?
I think that should be possible to embed directly each child-event
into the father-event (as illustrated before in a simplified way) or
to describe separately each child-event and to link it to the
father-event, by a mutual (<->) relationship, like, for example, in
xfn [ http://en.wikipedia.org/wiki/XHTML_Friends_Network ]:
?
?
Also a single relationship (->) can be permitted,
?
?
or
?
?
but a mutual relationship is a stronger link, that offers a guarantee,
a trusted certification of the link, especially if the informations
about the events are stored in different uris/urls.
In the future, webapps o apps will be able to automatically include
infos about child-events in the father-event, getting them directly
from other ical files, also through ajax technologies.
What do you think about this proposal?
Best regards
Ps: Tomorrow I'll leave for vacation and I'll come back on 19/08.
--
Lorenzo De Tomasi
Designer multimodale
http://www.ipernico.it
http://www.isotype.org (in costruzione)
From TimHare at comcast.net Thu Aug 2 05:48:20 2007
From: TimHare at comcast.net (Tim Hare)
Date: Thu Aug 2 05:49:32 2007
Subject: [Ietf-calsify] Proposal of "Collections of events"
In-Reply-To: <5c2a5c380708020359v3046d7d8vd357a41a217ffa5e@mail.gmail.com>
Message-ID: <20070802124829.9775F142207@laweleka.osafoundation.org>
This proposal, while interesting, is probably outside the scope of the WG.
The purpose of the WG was to try to simplify iCalendar and remove
impediments to interoperability between implementations. I don't think that
introducing new items will help interoperability at this time. (Note: I'm
not a member of the WG, just stating my opinion).
Tim Hare
Interested Bystander, Non-Inc.
-----Original Message-----
From: ietf-calsify-bounces@osafoundation.org
[mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Lorenzo De
Tomasi
Sent: Thursday, August 02, 2007 7:00 AM
To: Ietf-calsify@osafoundation.org
Subject: [Ietf-calsify] Proposal of "Collections of events"
I have read the draft and I think that it needs the support of Collections
of events.
Often, an event, especially when lasts more than one day, includes other
smaller events, contemporary or sequential, that can be organized as chinese
boxes.
Something like
.
.
or
.
I think that should be possible to embed directly each child-event into the
father-event (as illustrated before in a simplified way) or to describe
separately each child-event and to link it to the father-event, by a mutual
(<->) relationship, like, for example, in xfn [
http://en.wikipedia.org/wiki/XHTML_Friends_Network ]:
.
.
Also a single relationship (->) can be permitted,
.
.
or
.
.
but a mutual relationship is a stronger link, that offers a guarantee, a
trusted certification of the link, especially if the informations about the
events are stored in different uris/urls.
In the future, webapps o apps will be able to automatically include infos
about child-events in the father-event, getting them directly from other
ical files, also through ajax technologies.
What do you think about this proposal?
Best regards
Ps: Tomorrow I'll leave for vacation and I'll come back on 19/08.
--
Lorenzo De Tomasi
Designer multimodale
http://www.ipernico.it
http://www.isotype.org (in costruzione)
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
From bernard.desruisseaux at oracle.com Fri Aug 3 14:22:51 2007
From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Fri Aug 3 14:25:01 2007
Subject: [Ietf-calsify] Issue 63: Section 4.8.5.3 Recurrence Date/Times:
RDATE < DTSTART
Message-ID: <46B39CAB.7070303@oracle.com>
Disclaimer: This is the third time I bring up this issue. See:
http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001349.html
http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/001522.html
Cyrus recently brought up the fact that the deprecation of
RANGE=THISANDFUTURE (Issue 48) might be an issue with unbounded
recurring calendar components in the context of iTIP.
I have already suggested a solution for the case where an
organizer cancels all future recurrence instances of a
recurring calendar component. See:
http://lists.osafoundation.org/pipermail/ietf-calsify/2007-July/001746.html
This time I would like to suggest a solution for the case where
an organizer changes all future recurrence instances of a recurring
calendar component:
1- Specify RDATE properties for all past recurrence instances
and define exception components for them if needed. The
number of past recurrence instances is always finite...
2- Remove EXDATE properties for any past recurrence instances.
3- Set DTSTART to the first recurrence instance to which you
want the change to apply.
The only issue here is that we need to clarify that RDATE can
specify a value less than the value specified by DTSTART.
Cheers,
Bernard
From lisa at osafoundation.org Wed Aug 8 14:01:57 2007
From: lisa at osafoundation.org (Lisa Dusseault)
Date: Wed Aug 8 14:03:00 2007
Subject: [Ietf-calsify] Fwd: Review of media type form before submission to
IANA - knowledgeitem
References:
Message-ID: <8C18814C-F9C4-4606-B630-2AFAB349F880@osafoundation.org>
FYI -- note the EventML plans
Lisa
Begin forwarded message:
> From: "Jayson Lorenzen"
> Date: August 8, 2007 1:15:14 PM PDT
> To:
> Subject: Review of media type form before submission to IANA -
> knowledgeitem
>
>
> As per the instructions for registering media types based on XML which
> are outside of the five media types specified in rfc3023, and section
> 2.3.1 of rfc 2048. We (IPTC) are submitting the following potential
> media type registration for preliminary community review before
> submission to IANA.
>
> The IPTC ( http://www.iptc.org/ ), is a consortium of the world's
> major
> news agencies and news industry vendors. It develops and maintains
> technical standards for improved news exchange that are used by
> virtually every major news organization in the world.
>
> Currently about 65 companies and organisations from the news industry
> are members of the IPTC.
>
> Some of the standards currently maintained by IPTC:
> NewsML 1 http://www.newsml.org/
> NITF http://www.nitf.org/
> SportsML http://www.sportsml.org/
> IIM http://www.iptc.org/IIM/
> IPTC 7901 (ANPA) http://www.iptc.org/IPTC7901/
>
> The IPTC has decided to develop new family of news exchange
> standards -
> the G2-Standards - for conveying different types of content. They will
> be successors to the current versions of NewsML 1.x, SportsML 1.x.
> Further to that a standard for exchanging event information -
> EventsML -
> is also be developed at this stage.
>
> After an "Experimental Phase 1" (EP#1) in winter 2005/2006, another
> EP#2
> in summer 2006 and a final Release Candidate (RC) review in early 2007
> the structures of the News Architecture 1.0 were approved by the
> IPTC on
> 30 May 2007. This includes the data model and all properties but
> excludes the Processing Model.
>
> You may download the NAR 1.0 package, a ZIP file (
> http://www.iptc.org/std/NAR/NAR_1.0.zip ) containing these individual
> documents and also find more information about the G2 family of news
> exchange standards on the IPTC website at: http://www.iptc.org/NAR/
>
> What we are looking to do is to formally register media types based on
> XML for this new family of news exchange standards in the vendor tree.
> Specifically, with this request, we are seeking to register the
> following media type:
>
> application/vnd.iptc.g2.knowledgeitem+xml
>
> A version of the form we wish to submit follows. If this submission
> requires additional information for community review and IANA
> approval,
> please let us know.
>
>
> ---------- the form ----------
>
> Media Type Name: application
>
> Subtype name: vnd.iptc.g2.knowledgeitem+xml
>
> Required parameters: none
>
> Optional parameters: Identical to those of "application/xml" as
> described in rfc3023, section 3.2
>
>
> Encoding considerations: Identical to those of "application/xml" as
> described in rfc3023, section 3.2
>
> Security considerations: Identical to those of "application/xml" as
> described in rfc3023, section 10
>
>
> Interoperability considerations: Identical to those of "application/
> xml"
> as described in rfc3023, section 3.1
>
>
> Published specification:
>
> NAR_1.0-spec-ModelCore_16.pdf
>
> http://www.iptc.org/std/NAR/1.0/specification/NAR_1.0-spec-
> ModelCore_16.pdf
>
> NAR_1.0-spec-ModelPowerExt_16.pdf
>
> http://www.iptc.org/std/NAR/1.0/specification/NAR_1.0-spec-
> ModelPowerExt_16.pdf
>
>
>
> Applications which use this media type: none
>
> Additional information:
>
> Magic number(s): none
> File extension(s): xml
> Macintosh File Type Code(s): Identical to those of "application/xml"
> as described in rfc3023, "TEXT"
>
>
> Object Identifier(s) or OID(s):
>
> It must be possible to positively identify an Item as it moves through
> the news workflow, and is transferred from place to place and from
> system to system. An Item therefore gets a globally unique identifier
> (guid), which is a persistent, universally unique identifier, and a
> version which is incremented when the content of the Item is updated.
> The first version is numbered 1: if the version is not explicitly set,
> this value must be assumed by the recipient of the Item. The guid is
> required to be in the form of a IRI. Any IRI capable of acting as a
> globally unique identifier is accepted; the IPTC provides a
> standard for
> this purpose in the form of an IETF RFC [RFC-3085]. @@ At the time of
> this writing the RFC 3085, initially defined in the scope of
> NewsML1, is
> still to be complemented by a new RFC in which globally unique
> identifier and version are separate properties.
>
>
> Intended usage:
>
> Knowledge Item is a set of concept definitions or classes extended
> with
> specific properties, e.g. with specific information about a person
> grouped together to form a consistent structure, which is managed,
> protected and published as a whole. A Knowledge Item should be
> used to
> convey snapshots of the set of concepts adopted by a controlled
> vocabulary e.g. where a provider wants to circulate a set of entries
> from one or more controlled vocabularies, representing something
> like a
> thesaurus, a taxonomy or an authority list.
>
> Other Information/General Comment: none
>
>
> Person to contact for further information:
>
> Name: Michael Steidl
>
> E-mail: mdirector@iptc.org
>
>
> Author/Change controller:
>
> Name: Michael Steidl
>
> E-mail: mdirector@iptc.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070808/9d7f1b31/attachment-0001.htm
From lear at cisco.com Fri Aug 10 00:23:15 2007
From: lear at cisco.com (Eliot Lear)
Date: Fri Aug 10 00:24:33 2007
Subject: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07
ends TODAY
Message-ID: <46BC1263.5040002@cisco.com>
Please send your comments to the list.
Thanks,
Eliot
From lear at cisco.com Mon Aug 13 03:35:28 2007
From: lear at cisco.com (Eliot Lear)
Date: Mon Aug 13 03:36:39 2007
Subject: [Ietf-calsify] working group last call comments for
draft-ietf-calsify-rfc2445bis-07.txt
Message-ID: <46C033F0.6010203@cisco.com>
Dear all,
Working Group Last Call (WGLC) has now closed for
draft-ietf-calsify-rfc2445bis-07.txt. We received two messages during
WGLC. There are two forms of comments we will address: editorial and
substantial changes. The editor may use his discretion accept or reject
editorial comments. The working group must consider proposals for
substantial changes. What follows is the chair's opinion as to what is
editorial and what is substantial:
On the 3rd of August, Bernard proposed a change to close Issue 63. I
view this change as substantial and requiring working group input.
Now, breaking up Nigel Swinson's message of the 1st of August (thank
you, Nigel):
> Version 7 contains numerous additions of this form:
>
> "Applications MUST treat x-name and iana-token value they don't
> recognized the same way as the XXXX value."
>
> I don't think this is gramatically correct. I'd suggest:
>
> "Applications MUST treat x-name and iana-token values they don't
> recognize the same way as they would the XXXX value."
>
Editorial.
> Or better still rely on the existing description of what the default value
> is:
>
> "Applications MUST ignore x-name and iana-token values they don't
> recognize and revert to the default value for the parameter."
>
Substantial if reverting means changing the actual text of the invitation.
> This comment applies to:
> - 3.2. Property Parameters
> - 3.2.3. Calendar User Type
> - 3.2.9. Free/Busy Time Type
> - 3.2.12. Participation Status
> - 3.2.14. Relationship Type
> - 3.2.15. Participation Role
> - 3.2.19. Value Data Types
> - 3.8.1.3. Classification
> - 3.8.6.1. Action
>
> 3.3.10. Recurrence Rule
>
> The UNTIL rule part defines a DATE or DATE-TIME value which bounds
> the recurrence rule in an inclusive manner. If the value
> specified by UNTIL is synchronized with the specified recurrence,
> this DATE or DATE-TIME becomes the last instance of the
> recurrence. The value of the UNTIL rule part MUST have the same
> value type as the "DTSTART" property. Furthermore, if the
> "DTSTART" property is specified as a date with local time, then
> the UNTIL rule part MUST also be specified as a date with local
> - time. Else, if the "DTSTART" property is specified as a date with
> + time. If the "DTSTART" property is specified as a date with
>
Editorial.
> UTC time or a date with local time and time zone reference, then
> the UNTIL rule part MUST be specified as a date with UTC time. In
> the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
> - rule part MUST always be specified as a date with UTC time. If
> - specified as a DATE-TIME value, then it MUST be specified in a UTC
> - time format. If not present, and the COUNT rule part is also not
> + rule part MUST always be specified as a date with UTC time, with the
> + "DTSTART" always represented as a date with local time. If the UNTIL
> + and COUNT rule parts are not
>
Substantial.
> present, the "RRULE" is considered to repeat forever.
>
> Below I've re-ordered the sentences in addition to changing one word. I
> find changing from "the specific day" to "a specific day" helpful in warning
> that 3MO in a yearly rule isn't necessarily "the 3rd Monday in the year" and
> rather "a 3rd Monday in the year". Later we go on to describe in more
> detail how to interpret "a 3rd Monday in the year".
>
> Each BYDAY value can also be preceded by a positive (+n) or
> negative (-n) integer. If present, this indicates the nth
> - occurrence of the specific day within the MONTHLY or YEARLY
> + occurrence of a specific day within the MONTHLY or YEARLY
> "RRULE". For example, within a MONTHLY rule, +1MO (or simply 1MO)
> represents the first Monday within the month, whereas -1MO
> - represents the last Monday of the month. If an integer modifier
> + represents the last Monday of the month. The
> + numeric value in a BYDAY rule part with the FREQ rule part set to
> + YEARLY corresponds to an offset within the month when the BYMONTH
> + rule part is present, and corresponds to an offset within the year
> + when the BYWEEKNO or BYMONTH rule parts are present.
> + If an integer modifier
>
This seems to be editorial.
> is not present, it means all days of this type within the
> specified frequency. For example, within a MONTHLY rule, MO
> represents all Mondays within the month. The BYDAY rule part MUST
> NOT be specified with a numeric value when the FREQ rule part is
> not set to MONTHLY or YEARLY. Furthermore, the BYDAY rule part
> MUST NOT be specified with a numeric value with the FREQ rule part
> + set to YEARLY when the BYWEEKNO rule part is specified.
> - set to YEARLY when the BYWEEKNO rule part is specified. The
> - numeric value in a BYDAY rule part with the FREQ rule part set to
> - YEARLY corresponds to an offset within the month when the BYMONTH
> - rule part is present, and corresponds to an offset within the year
> - when the BYWEEKNO or BYMONTH rule parts are present.
>
>
Again, editorial.
> The BYYEARDAY rule part specifies a COMMA character (US-ASCII
> decimal 44) separated list of days of the year. Valid values are
> 1 to 366 or -366 to -1. For example, -1 represents the last day
> of the year (December 31st) and -306 represents the 306th to the
> last day of the year (March 1st). The BYYEARDAY rule part MUST
> NOT be specified when the FREQ rule part is set to DAILY, WEEKLY,
> - and MONTHLY.
> + or MONTHLY.
>
While some might view this as substantial, I believe this is editorial
because the working group discussed the intent here in depth, and Nigel
is correct in my opinion as to our interpretation.
> I think there's too many negatives in what was there:
>
> The BYWEEKNO rule part specifies a COMMA character (US-ASCII
> decimal 44) separated list of ordinals specifying weeks of the
> year. Valid values are 1 to 53 or -53 to -1. This corresponds to
> weeks according to week numbering as defined in [ISO.8601.2004].
> A week is defined as a seven day period, starting on the day of
> the week defined to be the week start (see WKST). Week number one
> of the calendar year is the first week which contains at least
> four (4) days in that calendar year. This rule part MUST NOT be
> - used when the FREQ rule part is not set to YEARLY. For example, 3
> + used when the FREQ rule part is set to anything other than YEARLY.
> + For example, 3
>
Editorial.
> represents the third week of the year.
>
> WRT to the text below I think we should either:
> - Say BYSETPOS is only valid with Weekly, Monthly, Yearly rules,
> - Specify what the "interval" for daily, hourly, minutely, secondly means.
> - Drop the new text, as I think the example is sufficient illustration.
> - Change the example to illustrate what obscurity it was that lead to the
> need for the new text.
>
> My vote would be to drop some of the new text to become:
>
> The BYSETPOS rule part specifies a COMMA character (US-ASCII
> decimal 44) separated list of values which corresponds to the nth
> occurrence within the set of recurrence instances specified by the
> rule. BYSETPOS operates on a set of recurrence instances in one
> - interval of the recurrence rule. For a WEEKLY rule, the interval
> - is one week, for a MONTHLY rule, one month, and for a YEARLY rule,
> - one year. Valid values are 1 to 366 or -366 to -1. It MUST only
> + interval of the recurrence rule.
> + Valid values are 1 to 366 or -366 to -1. It MUST only
> be used in conjunction with another BYxxx rule part. For example
> "the last work day of the month" could be represented as:
>
Substantial.
> FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
>
> Each BYSETPOS value can include a positive (+n) or negative (-n)
> integer. If present, this indicates the nth occurrence of the
> specific occurrence within the set of occurences specified by the
> rule.
>
> The phrase "special expand" is mentioned nowhere else in the document. I
> think the concept was better expressed by my suggestion from the 29th May.
> You merge the "Expand" cells in the Yearly/Monthly columns to illustrate
> that each creates a set, and when taken together it's the union of the sets.
> Also even with a numeric modifier on ByDay, it's still the case that
> Monthly/Yearly + BYDAY will expand, and while it's true that numeric
> modifiers on ByDay with yearly rules requires attention, I think it's
> adequately dealt with in the paragraphs above on ByDay. So I'd make it:
>
> - BYDAY has some special behaviour depending on the FREQ value and
> - this is described in separate notes below the table.
>
> +----------+--------+--------+-------+-------+------+-------+------+
> | |SECONDLY|MINUTELY|HOURLY |DAILY |WEEKLY|MONTHLY|YEARLY|
> +----------+--------+--------+-------+-------+------+-------+------+
> - |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit |Expand|
> - +----------+--------+--------+-------+-------+------+-------+------+
> - |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A |Expand|
> - +----------+--------+--------+-------+-------+------+-------+------+
> - |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand|
> - +----------+--------+--------+-------+-------+------+-------+------+
> - |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A |Expand |Expand|
> - +----------+--------+--------+-------+-------+------+-------+------+
> - |BYDAY |Limit |Limit |Limit |Limit |Expand|Note 1 |Note 2|
> - +----------+--------+--------+-------+-------+------+-------+------+
> + |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit | |
> + +----------+--------+--------+-------+-------+------+-------+ +
> + |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A | |
> + +----------+--------+--------+-------+-------+------+-------+ +
> + |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand|
> + +----------+--------+--------+-------+-------+------+-------+ +
> + |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A | | |
> + +----------+--------+--------+-------+-------+------+Expand + +
> + |BYDAY |Limit |Limit |Limit |Limit |Expand| | |
> + +----------+--------+--------+-------+-------+------+-------+------+
> |BYHOUR |Limit |Limit |Limit |Expand |Expand|Expand |Expand|
> +----------+--------+--------+-------+-------+------+-------+------+
> |BYMINUTE |Limit |Limit |Expand |Expand |Expand|Expand |Expand|
> +----------+--------+--------+-------+-------+------+-------+------+
> |BYSECOND |Limit |Expand |Expand |Expand |Expand|Expand |Expand|
> +----------+--------+--------+-------+-------+------+-------+------+
> |BYSETPOS |Limit |Limit |Limit |Limit |Limit |Limit |Limit |
> +----------+--------+--------+-------+-------+------+-------+------+
>
> - Note 1: Limit if BYMONTHDAY is present, otherwise special expand
> - for MONTHLY.
> -
> - Note 2: Limit if BYYEARDAY or BYMONTHDAY is present, otherwise
> - special expand for WEEKLY if BYWEEKNO present, otherwise
> - special expand for MONTHLY if BYMONTH present, otherwise
> - special expand for YEARLY.
>
> + In YEARLY rules, BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY and BYDAY
> work
> + together to expand the recurrence set. Each on their own will
> specify
> + a range of valid instances, and when used in combination it is the
> union
> + of all ranges that create the required recurrence set. So for
> example
> + in a YEARLY rule BYDAY=MO will mean every Monday, and BYMONTHDAY=1
> will
> + mean the first of every month, so when used together they mean the
> first of
> + every month, but only when it's a Monday. It would not mean on the
> first
> + of every month and also on every Monday. Likewise in MONTHLY rules,
> + BYMONTHDAY and BYDAY work together to expand the recurrence set.
>
Substantial and editorial. The combining of boxes is editorial.
> 3.6. Calendar Components
>
> An iCalendar object MUST include the "PRODID" and "VERSION" calendar
> properties. In addition, it MUST include at least one calendar
> component. Special forms of iCalendar objects are possible to
> publish just busy time (i.e., only a "VFREEBUSY" calendar component)
> or time zone (i.e., only a "VTIMEZONE" calendar component)
> information. In addition, a complex iCalendar object that is used to
> capture a complete snapshot of the contents of a calendar is possible
> (e.g., composite of many different calendar components). More
> commonly, an iCalendar object will consist of just a single "VEVENT",
> "VTODO" or "VJOURNAL" calendar component. Applications MUST ignore
> - x-comp and iana-comp they don't recognized.
> + x-comp and iana-comp they don't recognize.
>
Editorial.
> 3.8.1.1. Attachment
>
> Conformance: This property can be specified multiple times in a
> "VEVENT", "VTODO", "VJOURNAL" or "VALARM" calendar component with
> - the exception of AUDIO alarm which only allow this property to
> + the exception of AUDIO alarm which only allows this property to
> occur once.
>
Editorial.
> 3.8.2.3. Date/Time Due
>
> - Description: This property defines the date and time that a to-do is
> + Description: This property defines the date and time before which a
>
Editorial.
> to-do is
> expected to be completed. For cases where this property is
> specified in a "VTODO" calendar component that also specifies a
> "DTSTART" property, the value type of this property MUST be the
> same as the "DTSTART" property, and the value of this property
> MUST be later in time than the value of the "DTSTART" property.
> Furthermore, this property MUST be specified as a date with local
> time if and only if the "DTSTART" property is also specified as a
> date with local time.
>
> 3.8.6.2. Repeat Count
> - Description: This property defines the number of time an alarm
> + Description: This property defines the number of times an alarm
>
Editorial.
> should be repeated after its initial trigger. If the alarm
> triggers more than once, then this property MUST be specified
> along with the "DURATION" property.
>
> 3.8.7.2. Date/Time Stamp
>
> In the case of an iCalendar object that specifies a "METHOD"
> - property, this property is different than the "CREATED" and "LAST-
> + property, this property is different to the "CREATED" and "LAST-
>
Editorial. Suggestion: "this property differs from".
> MODIFIED" properties. These two properties are used to specify
> when the particular calendar data in the calendar store was
> created and last modified. This is different than when the
> iCalendar object representation of the calendar service
> information was created or last modified.
>
> Cheers,
>
> Nigel
>
>
Thanks again,
Eliot
From lennox at cs.columbia.edu Mon Aug 13 08:56:40 2007
From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Mon Aug 13 08:57:40 2007
Subject: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07
ends TODAY
In-Reply-To: <46BC1263.5040002@cisco.com>
References: <46BC1263.5040002@cisco.com>
Message-ID: <18112.32568.616017.127025@cnr.cs.columbia.edu>
I'm very sorry -- I should have sent these comments earlier. (I was sick on
Friday, and did not see the reminder e-mail until this morning.)
I have several comments on section 3.3.6 (DURATION).
First of all, one of the items in the text I sent in May (in the message
)
didn't get applied to this draft; I think it's uncontroversial but a fairly
important corner case.
Add the text (wordsmithing as appropriate):
+ If the local time when a nominal duration would end does not exist,
+ or occurs more than once, in the duration's timezone, it is
+ interpreted in the same manner as an explicit DATE-TIME value
+ describing that date and time, as specified in section 3.3.5.
Editorially, this section has the problem that it uses the terms "nominal
duration", "accurate duration", and "exact duration" without defining them.
The definitions can be semi-inferred from context, but I'd be curious if
someone who hasn't wrestled with these issues as much as I have can
understand the text.
I also think that the discussion of adding weeks, days, hours, minutes, and
seconds in that strict order -- when actually all that matters is that
nominal durations (weeks + days) be added before accurate durations (hours,
minutes, and seconds) -- is confusing; it leads the reader to think there's
some significance to the order of the arithmetic operations within each section.
I have two spelling/grammar fixes in this section as well:
The duration of a week or a day depends on its position in the
calendar. In the case of discontinuities in the time scale, such
as the change from standard time to daylight time and back, the
- computation of the exact duration requires the substraction or
+ computation of the exact duration requires the subtraction or
addition of the change of duration of the discontinuity. Leap
seconds MUST NOT be considered when computing an exact duration.
...
No additional content value encoding (i.e., BACKSLASH character
- encoding) are defined for this value type.
+ encoding) is defined for this value type.
The one other stylistic comment I'd make on the changes introduced in
version -07 is that it's not usually appropriate to use contractions
("don't", "doesn't", etc.) in formal standards writing. These should be
expanded to "do not", "does not", etc.
--
Jonathan Lennox
lennox@cs.columbia.edu
From lennox at cs.columbia.edu Mon Aug 13 09:08:39 2007
From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Mon Aug 13 09:09:41 2007
Subject: [Ietf-calsify] One last comment on exact vs. nominal durations
In-Reply-To: <46BC1263.5040002@cisco.com>
References: <46BC1263.5040002@cisco.com>
Message-ID: <18112.33287.205615.836886@cnr.cs.columbia.edu>
One other issue occured to me on exact vs. nominal durations.
The definition of RRULE says:
If the duration of the recurring component is specified with the
"DTEND" or "DUE" property, then the same exact duration will apply
to all the members of the generated recurrence set.
This is correct for DTEND or DUE specified with VALUE=DATE-TIME, but I think
it's wrong for DTEND or DUE (and thus also DTSTART) with VALUE=DATE. In
this latter case, I think it's clear that the desired outcome is always
for the event to last a nominal number of days, not the exact duration of
time of the first instance of the recurrence set.
Is this worth addressing?
--
Jonathan Lennox
lennox@cs.columbia.edu
From lennox at cs.columbia.edu Mon Aug 13 10:51:41 2007
From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Mon Aug 13 10:52:41 2007
Subject: [Ietf-calsify] One more 2445bis WGLC comment: DTSTART matching
"pattern of the recurrence rule"
In-Reply-To: <46BC1263.5040002@cisco.com>
References: <46BC1263.5040002@cisco.com>
Message-ID: <18112.39469.783367.197741@cnr.cs.columbia.edu>
There's one other comment I had that Bernard asked me about at the Chicago
IETF.
The section on RRULE says that
The "DTSTART" property
value SHOULD match the pattern of the recurrence rule, if
specified. The recurrence set generated with a "DTSTART" property
value that doesn't match the pattern of the rule is undefined.
(For some reason I don't understand, this text also appears in the RDATE and
EXDATE sections, but leave that aside for now.)
The question is whether the DTSTART can match "the pattern of the recurrence
rule" if the rule specifies BYSETPOS values not including the value 1. If
"the pattern" has its obvious definition, I think that it can't.
The obvious fix would be to change the above to
The "DTSTART" property value SHOULD match the pattern of the recurrence
rule (not including any BYSETPOS value), if specified.
--
Jonathan Lennox
lennox@cs.columbia.edu
From TimHare at comcast.net Mon Aug 13 15:43:19 2007
From: TimHare at comcast.net (Tim Hare)
Date: Mon Aug 13 15:44:19 2007
Subject: [Ietf-calsify] A question inspired by Eliot's e-mail
In-Reply-To: <46C033F0.6010203@cisco.com>
Message-ID: <20070813224322.5C382142211@laweleka.osafoundation.org>
Specifically, these statements:
"While some might view this as substantial, I believe this is editorial
because the working group discussed the intent here in depth, and Nigel is
correct in my opinion as to our interpretation."
Interpretation of intent was one of the things we used to have long
discussions about on previous calendar lists, related to the original RFCs.
So, I'm inspired to ask: how will we judge if we have, in fact, simplified
things and improved interoperability? Is there any forum where we could get
the input of vendors and developers on that topic?
Note that this is NOT an opinion on the RFC itself, one way or another.
Tim Hare
Interested Bystander, Non-Inc.
From lear at cisco.com Tue Aug 14 05:14:02 2007
From: lear at cisco.com (Eliot Lear)
Date: Tue Aug 14 05:15:10 2007
Subject: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07
ends TODAY
In-Reply-To: <18112.32568.616017.127025@cnr.cs.columbia.edu>
References: <46BC1263.5040002@cisco.com>
<18112.32568.616017.127025@cnr.cs.columbia.edu>
Message-ID: <46C19C8A.2040803@cisco.com>
Jonathan,
Thank you for your comments. So long as there are no objections I see
no reason not to include them as part of last call comments. Let's just
go through this set as I did the others.
Please see below.
Jonathan Lennox wrote:
> I'm very sorry -- I should have sent these comments earlier. (I was sick on
> Friday, and did not see the reminder e-mail until this morning.)
>
>
> I have several comments on section 3.3.6 (DURATION).
>
> First of all, one of the items in the text I sent in May (in the message
> )
> didn't get applied to this draft; I think it's uncontroversial but a fairly
> important corner case.
>
> Add the text (wordsmithing as appropriate):
>
> + If the local time when a nominal duration would end does not exist,
> + or occurs more than once, in the duration's timezone, it is
> + interpreted in the same manner as an explicit DATE-TIME value
> + describing that date and time, as specified in section 3.3.5.
>
Substantial.
>
> Editorially, this section has the problem that it uses the terms "nominal
> duration", "accurate duration", and "exact duration" without defining them.
> The definitions can be semi-inferred from context, but I'd be curious if
> someone who hasn't wrestled with these issues as much as I have can
> understand the text.
>
>
> I also think that the discussion of adding weeks, days, hours, minutes, and
> seconds in that strict order -- when actually all that matters is that
> nominal durations (weeks + days) be added before accurate durations (hours,
> minutes, and seconds) -- is confusing; it leads the reader to think there's
> some significance to the order of the arithmetic operations within each section.
>
>
> I have two spelling/grammar fixes in this section as well:
>
> The duration of a week or a day depends on its position in the
> calendar. In the case of discontinuities in the time scale, such
> as the change from standard time to daylight time and back, the
> - computation of the exact duration requires the substraction or
> + computation of the exact duration requires the subtraction or
> addition of the change of duration of the discontinuity. Leap
> seconds MUST NOT be considered when computing an exact duration.
>
Editorial.
> ...
>
> No additional content value encoding (i.e., BACKSLASH character
> - encoding) are defined for this value type.
> + encoding) is defined for this value type.
>
Editorial.
>
>
> The one other stylistic comment I'd make on the changes introduced in
> version -07 is that it's not usually appropriate to use contractions
> ("don't", "doesn't", etc.) in formal standards writing. These should be
> expanded to "do not", "does not", etc.
>
Editorial.
Eliot
From lear at cisco.com Tue Aug 14 05:15:44 2007
From: lear at cisco.com (Eliot Lear)
Date: Tue Aug 14 05:16:52 2007
Subject: [Ietf-calsify] One last comment on exact vs. nominal durations
In-Reply-To: <18112.33287.205615.836886@cnr.cs.columbia.edu>
References: <46BC1263.5040002@cisco.com>
<18112.33287.205615.836886@cnr.cs.columbia.edu>
Message-ID: <46C19CF0.1070201@cisco.com>
Jonathan Lennox wrote:
> One other issue occured to me on exact vs. nominal durations.
>
> The definition of RRULE says:
>
> If the duration of the recurring component is specified with the
> "DTEND" or "DUE" property, then the same exact duration will apply
> to all the members of the generated recurrence set.
>
> This is correct for DTEND or DUE specified with VALUE=DATE-TIME, but I think
> it's wrong for DTEND or DUE (and thus also DTSTART) with VALUE=DATE. In
> this latter case, I think it's clear that the desired outcome is always
> for the event to last a nominal number of days, not the exact duration of
> time of the first instance of the recurrence set.
>
> Is this worth addressing?
>
>
Substantial
From lear at cisco.com Tue Aug 14 05:16:16 2007
From: lear at cisco.com (Eliot Lear)
Date: Tue Aug 14 05:17:23 2007
Subject: [Ietf-calsify] One more 2445bis WGLC comment: DTSTART matching
"pattern of the recurrence rule"
In-Reply-To: <18112.39469.783367.197741@cnr.cs.columbia.edu>
References: <46BC1263.5040002@cisco.com>
<18112.39469.783367.197741@cnr.cs.columbia.edu>
Message-ID: <46C19D10.906@cisco.com>
Jonathan Lennox wrote:
> There's one other comment I had that Bernard asked me about at the Chicago
> IETF.
>
> The section on RRULE says that
>
> The "DTSTART" property
> value SHOULD match the pattern of the recurrence rule, if
> specified. The recurrence set generated with a "DTSTART" property
> value that doesn't match the pattern of the rule is undefined.
>
> (For some reason I don't understand, this text also appears in the RDATE and
> EXDATE sections, but leave that aside for now.)
>
> The question is whether the DTSTART can match "the pattern of the recurrence
> rule" if the rule specifies BYSETPOS values not including the value 1. If
> "the pattern" has its obvious definition, I think that it can't.
>
> The obvious fix would be to change the above to
>
> The "DTSTART" property value SHOULD match the pattern of the recurrence
> rule (not including any BYSETPOS value), if specified.
>
>
Substantial.
From aki.niemi at nokia.com Fri Aug 24 04:33:42 2007
From: aki.niemi at nokia.com (Aki Niemi)
Date: Fri Aug 24 04:35:05 2007
Subject: [Ietf-calsify] Draft minutes uploaded
Message-ID: <46CEC216.2070406@nokia.com>
All,
The IETF69 minutes have been posted here:
http://www3.ietf.org/proceedings/07jul/minutes/calsify.txt
If you have comments or corrections, sent them to me.
Cheers,
Aki
From andrew_dowden at softdesign.net.nz Fri Aug 24 16:27:06 2007
From: andrew_dowden at softdesign.net.nz (Andrew N Dowden)
Date: Fri Aug 24 16:28:10 2007
Subject: [Ietf-calsify] Draft minutes uploaded
In-Reply-To: <46CEC216.2070406@nokia.com>
References: <46CEC216.2070406@nokia.com>
Message-ID: <46CF694A.1030209@softdesign.net.nz>
Aki Niemi wrote:
> If you have comments or corrections, sent them to me.
>
Sorry, I wrote this weeks ago when I was focusing on technical aspects ..
rfc2445bis-07
current ( from 3.8.5.2. - RDATE, also occurs in 3.8.5.1. & 3.8.5.3. )
The final recurrence set is generated by gathering all of the start
date-times generated by any of the specified "RRULE" and
"RDATE" properties, and then excluding any start date and times
specified by "EXDATE" properties. This implies that start
date/times specified by "EXDATE" properties take precedence over
those specified by inclusion properties (i.e., "RDATE" and "RRULE").
Where duplicate instances are generated by the "RRULE" and "RDATE"
properties, only one recurrence is considered. Duplicate
instances are
ignored.
tidyup ( for clarity, with NO change of meaning )
The final recurrence set contains those start date-times generated by
any of the specified "RRULE" and "RDATE" properties, after
excluding any start date-times specified by "EXDATE" properties.
The "EXDATE" property taking precedence over "RDATE" and "RRULE".
Where duplicate instances are generated from multiple "RRULE" and/or
"RDATE" properties, only one instance is included.
--
_______________________________________________
SoftDesign Group
Dowden Software Associates
P O Box 31 132, Lower Hutt 5040, NEW ZEALAND
From dthewlis at dcta.com Wed Aug 29 09:36:34 2007
From: dthewlis at dcta.com (David C. Thewlis)
Date: Wed Aug 29 09:37:50 2007
Subject: [Ietf-calsify] Quick Reminder: CalConnect Roundtable X and
Interoperability Test
Event -September 17-21, Cambridge, Massachusetts
Message-ID: <46D5A092.7090007@dcta.com>
A quick reminder that the CalConnect Roundtable and IOP test event is
only about three weeks away, and the registration fee for the Roundtable
goes up (a little) after September 3rd. Hotels rooms appear to have
become predictably scarce, but don't let that dissuade you. We hope to
see you at M.I.T.!*
*
Logistics and registration information may be found at
http://www.calconnect.org/roundtable10.shtml and at
http://www.calconnect.org/iopseptember2007.shtml
If you are not currently a member of the Consortium, you may attend a
single Roundtable, or a single IOP test event, as an observer; see
http://www.calconnect.org/observer.shtml for more information.
Dave Thewlis
--
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) ? +1 707 498 2238 (mobile)
http://www.calconnect.org ? Dave.Thewlis@calconnect.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070829/06535710/attachment.htm
From Dave.Thewlis at calconnect.org Wed Aug 29 09:40:10 2007
From: Dave.Thewlis at calconnect.org (Dave Thewlis)
Date: Wed Aug 29 09:41:22 2007
Subject: [Ietf-calsify]
Reminder: CalConnect vCard Workshop - September 18, 2007 - Cambridge,
Massachusetts
Message-ID: <46D5A16A.3090907@calconnect.org>
Reminder: The CalConnect vCard Workshop is coming up on Tuesday,
September 18th, at M.I.T. in Cambridge.
---
CalConnect invites you to a a one-day open workshop on vCard and what
should be done about it on Tuesday, September 18, 2007, at M.I.T. in
Cambridge, Massachusetts. This event is _open_ to vendors, customers,
CalConnect members and non-members alike. There is no fee, but you
_must_ register in advance and numbers are limited. Please see
http://www.calconnect.org/vcardworkshop.shtml for more information and
links to the registration and
logistics
pages, a general discussion list
about the workshop,
and a questionnaire
to give us more guidance to make the workshop as productive as possible.
>From the workshop introduction page:
vCard is a well established standard for representing and transferring
contact information on computer systems and mobile devices. Having been
in use for a while, a number of areas of the specification have been
noted as problematic and in need of revision for fixes or enhancements.
To that end, CalConnect (the Calendaring & Scheduling Consortium) is
hosting a one day vCard-focused workshop event at M.I.T. in Cambridge,
Massachusetts in September with the goal of bringing together the key
players to help move forward vCard revision efforts.
Note that an effort is already under way at the IETF (Internet
Engineering Task Force) to develop a personal address book access
protocol based on the CardDAV specification, and since that is based on
vCard, a revision of the vCard specification will be taking place within
the IETF. However, bringing together interested parties in a focused
discussion at a workshop can help drive that effort and provide
supporting input to it to ensure the specific needs of the key players
is covered.
The goal of the workshop is two-fold. First to determine the real
interest in revising the vCard specification, and second to determine
what needs to be revised and how to go about doing that.
If you are not a CalConnect member, this is also an opportunity to stay
on for Roundtable X as an
observer, and we'd be delighted to have you; you will have to register
separately for the Roundtable.
Regardless of whether or not you are interested in attending the
workshop, we would appreciate it very much if you would take a few
minutes to fill out the questionnaire
, as this will help
provide the workshop participants with guidance as to the directions any
progression on vCard should take.
--
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) ? +1 707 498 2238 (mobile)
http://www.calconnect.org ? Dave.Thewlis@calconnect.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070829/0fb70d5c/attachment.html
Return-Path:
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 454C08094B for ; Wed, 29 Aug 2007 09:41:21 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5952E14221E for ; Wed, 29 Aug 2007 09:40:26 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.418
X-Spam-Level:
X-Spam-Status: No, score=-2.418 tagged_above=-50 required=4 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMq8cw+2jDdY for ; Wed, 29 Aug 2007 09:40:22 -0700 (PDT)
Received: from redwood.morsemedia.net (redwood.morsemedia.net [69.50.246.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CA57F142212 for ; Wed, 29 Aug 2007 09:40:22 -0700 (PDT)
Received: from [75.111.50.119] (helo=[192.168.0.103]) by redwood.morsemedia.net with esmtpa (Exim 4.66) (envelope-from ) id 1IQQad-0005be-6r; Wed, 29 Aug 2007 09:40:23 -0700
Message-ID: <46D5A16A.3090907@calconnect.org>
Date: Wed, 29 Aug 2007 09:40:10 -0700
From: Dave Thewlis
Organization: The Calendaring and Scheduling Consortium
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: ietf-calsify list
Content-Type: multipart/alternative; boundary="------------070307060708020106080606"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - redwood.morsemedia.net
X-AntiAbuse: Original Domain - osafoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - calconnect.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: [Ietf-calsify] Reminder: CalConnect vCard Workshop - September 18, 2007 - Cambridge, Massachusetts
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Dave.Thewlis@calconnect.org
List-Id: "RFC2445, 2446 and 2447 Discusions"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 29 Aug 2007 16:41:21 -0000
This is a multi-part message in MIME format.
--------------070307060708020106080606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Reminder: The CalConnect vCard Workshop is coming up on Tuesday,
September 18th, at M.I.T. in Cambridge.
---
CalConnect invites you to a a one-day open workshop on vCard and what
should be done about it on Tuesday, September 18, 2007, at M.I.T. in
Cambridge, Massachusetts. This event is _open_ to vendors, customers,
CalConnect members and non-members alike. There is no fee, but you
_must_ register in advance and numbers are limited. Please see
http://www.calconnect.org/vcardworkshop.shtml for more information and
links to the registration and
logistics
pages, a general discussion list
about the workshop,
and a questionnaire
to give us more guidance to make the workshop as productive as possible.
>From the workshop introduction page:
vCard is a well established standard for representing and transferring
contact information on computer systems and mobile devices. Having been
in use for a while, a number of areas of the specification have been
noted as problematic and in need of revision for fixes or enhancements.
To that end, CalConnect (the Calendaring & Scheduling Consortium) is
hosting a one day vCard-focused workshop event at M.I.T. in Cambridge,
Massachusetts in September with the goal of bringing together the key
players to help move forward vCard revision efforts.
Note that an effort is already under way at the IETF (Internet
Engineering Task Force) to develop a personal address book access
protocol based on the CardDAV specification, and since that is based on
vCard, a revision of the vCard specification will be taking place within
the IETF. However, bringing together interested parties in a focused
discussion at a workshop can help drive that effort and provide
supporting input to it to ensure the specific needs of the key players
is covered.
The goal of the workshop is two-fold. First to determine the real
interest in revising the vCard specification, and second to determine
what needs to be revised and how to go about doing that.
If you are not a CalConnect member, this is also an opportunity to stay
on for Roundtable X as an
observer, and we'd be delighted to have you; you will have to register
separately for the Roundtable.
Regardless of whether or not you are interested in attending the
workshop, we would appreciate it very much if you would take a few
minutes to fill out the questionnaire
, as this will help
provide the workshop participants with guidance as to the directions any
progression on vCard should take.
--
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------070307060708020106080606
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Reminder: The CalConnect vCard Workshop is coming up on Tuesday,
September 18th, at M.I.T. in Cambridge.
---
CalConnect invites you to a a one-day open workshop on vCard and what
should be done about it on Tuesday, September 18, 2007, at M.I.T. in
Cambridge, Massachusetts. This event is open to vendors,
customers, CalConnect members and non-members alike. There is no fee,
but you must register in advance and numbers are limited.
Please see
http://www.calconnect.org/vcardworkshop.shtml
for more information and links to the registration and logistics
pages, a general discussion
list about the workshop, and a questionnaire
to give us more guidance to make the workshop as productive as possible.
>From the workshop introduction page:
vCard is a well established standard for
representing and transferring contact information on computer systems
and mobile devices. Having been in use for a while, a number of areas
of the specification have been noted as problematic and in need of
revision for fixes or enhancements. To that end, CalConnect (the
Calendaring & Scheduling Consortium) is hosting a one day
vCard-focused workshop event at M.I.T. in Cambridge, Massachusetts in
September with the goal of bringing together the key players to help
move forward vCard revision efforts.
Note that an effort is already under way at the IETF (Internet
Engineering Task Force) to develop a personal address book access
protocol based on the CardDAV specification, and since that is based on
vCard, a revision of the vCard specification will be taking place
within the IETF. However, bringing together interested parties in a
focused discussion at a workshop can help drive that effort and provide
supporting input to it to ensure the specific needs of the key players
is covered.
The goal of the workshop is two-fold. First to determine the real
interest in revising the vCard specification, and second to determine
what needs to be revised and how to go about doing that.
If you are not a CalConnect member, this is also an opportunity to stay
on for Roundtable
X as an observer, and we'd be delighted to have you; you will have
to register separately for the Roundtable.
Regardless of whether or not you are interested in attending the
workshop, we would appreciate it very much if you would take a few
minutes to fill out the questionnaire,
as this will help provide the workshop participants with guidance as to
the directions any progression on vCard should take.
--------------070307060708020106080606--
Return-Path:
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 57FC680902 for ; Wed, 29 Aug 2007 09:37:48 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6DE71142213 for ; Wed, 29 Aug 2007 09:36:53 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.226
X-Spam-Level:
X-Spam-Status: No, score=-2.226 tagged_above=-50 required=4 tests=[AWL=-0.124, BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjtzEGF6Eqe5 for ; Wed, 29 Aug 2007 09:36:50 -0700 (PDT)
Received: from redwood.morsemedia.net (redwood.morsemedia.net [69.50.246.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 099EE1421F7 for ; Wed, 29 Aug 2007 09:36:49 -0700 (PDT)
Received: from [75.111.50.119] (helo=[192.168.0.103]) by redwood.morsemedia.net with esmtpa (Exim 4.66) (envelope-from ) id 1IQQX9-0005IF-8M; Wed, 29 Aug 2007 09:36:47 -0700
Message-ID: <46D5A092.7090007@dcta.com>
Date: Wed, 29 Aug 2007 09:36:34 -0700
From: "David C. Thewlis"
Organization: DCTA Inc.
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: ietf-calsify list
Content-Type: multipart/alternative; boundary="------------040601040008090209010903"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - redwood.morsemedia.net
X-AntiAbuse: Original Domain - osafoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - dcta.com
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: [Ietf-calsify] Quick Reminder: CalConnect Roundtable X and Interoperability Test Event -September 17-21, Cambridge, Massachusetts
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Dave.Thewlis@calconnect.org, dthewlis@dcta.com
List-Id: "RFC2445, 2446 and 2447 Discusions"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 29 Aug 2007 16:37:49 -0000
This is a multi-part message in MIME format.
--------------040601040008090209010903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
A quick reminder that the CalConnect Roundtable and IOP test event is
only about three weeks away, and the registration fee for the Roundtable
goes up (a little) after September 3rd. Hotels rooms appear to have
become predictably scarce, but don't let that dissuade you. We hope to
see you at M.I.T.!*
*
Logistics and registration information may be found at
http://www.calconnect.org/roundtable10.shtml and at
http://www.calconnect.org/iopseptember2007.shtml
If you are not currently a member of the Consortium, you may attend a
single Roundtable, or a single IOP test event, as an observer; see
http://www.calconnect.org/observer.shtml for more information.
Dave Thewlis
--
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------040601040008090209010903
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
A quick reminder that the CalConnect Roundtable and IOP test event is
only about three weeks away, and the registration fee for the
Roundtable goes up (a little) after September 3rd. Hotels rooms appear
to have become predictably scarce, but don't let that dissuade you. We
hope to see you at M.I.T.!
Logistics and registration information may be found at http://www.calconnect.org/roundtable10.shtml
and at http://www.calconnect.org/iopseptember2007.shtml
If you are not currently a member of the Consortium, you may attend a
single Roundtable, or a single IOP test event, as an observer; see http://www.calconnect.org/observer.shtml
for more information.
Dave Thewlis
--------------040601040008090209010903--
Return-Path:
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id ACAF380881 for ; Fri, 24 Aug 2007 16:28:08 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C49EE142203 for ; Fri, 24 Aug 2007 16:27:13 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.389
X-Spam-Level:
X-Spam-Status: No, score=-1.389 tagged_above=-50 required=4 tests=[AWL=1.075, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bk7LM+cMe9Js for ; Fri, 24 Aug 2007 16:27:11 -0700 (PDT)
Received: from smtp11.ihug.co.nz (smtp11.ihug.co.nz [203.109.136.111]) by laweleka.osafoundation.org (Postfix) with ESMTP id DF32B142202 for ; Fri, 24 Aug 2007 16:27:08 -0700 (PDT)
Received: from cust.filter3.content.ihug.net.nz (smtp.mailfilter3.ihug.co.nz) [10.80.50.3] by smtp11.ihug.co.nz with esmtp (Exim 4.60 #1 (Debian); Ihug conf #192) id 1IOiYT-00077Y-V5; Sat, 25 Aug 2007 11:27:05 +1200
Ironport-Content-Filter: send-to-smtp
Received: from 121-73-60-39.cable.telstraclear.net (HELO [127.0.0.1]) ([121.73.60.39]) by smtp.mailfilter3.ihug.co.nz with ESMTP; 25 Aug 2007 11:27:05 +1200
Message-ID: <46CF694A.1030209@softdesign.net.nz>
Date: Sat, 25 Aug 2007 11:27:06 +1200
From: Andrew N Dowden
Organization: Dowden Software Associates
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Aki Niemi
Subject: Re: [Ietf-calsify] Draft minutes uploaded
References: <46CEC216.2070406@nokia.com>
In-Reply-To: <46CEC216.2070406@nokia.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "ietf-calsify@osafoundation.org"
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 24 Aug 2007 23:28:08 -0000
Aki Niemi wrote:
> If you have comments or corrections, sent them to me.
>
Sorry, I wrote this weeks ago when I was focusing on technical aspects ..
rfc2445bis-07
current ( from 3.8.5.2. - RDATE, also occurs in 3.8.5.1. & 3.8.5.3. )
The final recurrence set is generated by gathering all of the start
date-times generated by any of the specified "RRULE" and
"RDATE" properties, and then excluding any start date and times
specified by "EXDATE" properties. This implies that start
date/times specified by "EXDATE" properties take precedence over
those specified by inclusion properties (i.e., "RDATE" and "RRULE").
Where duplicate instances are generated by the "RRULE" and "RDATE"
properties, only one recurrence is considered. Duplicate
instances are
ignored.
tidyup ( for clarity, with NO change of meaning )
The final recurrence set contains those start date-times generated by
any of the specified "RRULE" and "RDATE" properties, after
excluding any start date-times specified by "EXDATE" properties.
The "EXDATE" property taking precedence over "RDATE" and "RRULE".
Where duplicate instances are generated from multiple "RRULE" and/or
"RDATE" properties, only one instance is included.
--
_______________________________________________
SoftDesign Group
Dowden Software Associates
P O Box 31 132, Lower Hutt 5040, NEW ZEALAND
Return-Path:
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D53F68012F for ; Fri, 24 Aug 2007 04:35:03 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E6957142201 for ; Fri, 24 Aug 2007 04:34:08 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.664
X-Spam-Level:
X-Spam-Status: No, score=-1.664 tagged_above=-50 required=4 tests=[AWL=0.935, BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOasJ-vEDW5g for ; Fri, 24 Aug 2007 04:34:03 -0700 (PDT)
Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 808EE1421FF for ; Fri, 24 Aug 2007 04:34:03 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7OBXSk8015924 for ; Fri, 24 Aug 2007 14:33:59 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 14:33:49 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 14:33:49 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 14:33:48 +0300
Received: from [172.21.41.208] (esdhcp041208.research.nokia.com [172.21.41.208]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7OBXgDV014428 for ; Fri, 24 Aug 2007 14:33:47 +0300
Message-ID: <46CEC216.2070406@nokia.com>
Date: Fri, 24 Aug 2007 14:33:42 +0300
From: Aki Niemi
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: "ietf-calsify@osafoundation.org"
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Aug 2007 11:33:48.0773 (UTC) FILETIME=[A371E950:01C7E642]
X-Nokia-AV: Clean
Subject: [Ietf-calsify] Draft minutes uploaded
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 24 Aug 2007 11:35:04 -0000
All,
The IETF69 minutes have been posted here:
http://www3.ietf.org/proceedings/07jul/minutes/calsify.txt
If you have comments or corrections, sent them to me.
Cheers,
Aki
Return-Path:
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 15F21805EB for ; Tue, 14 Aug 2007 05:17:22 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2B8C4142219 for ; Tue, 14 Aug 2007 05:16:27 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.731
X-Spam-Level:
X-Spam-Status: No, score=-1.731 tagged_above=-50 required=4 tests=[AWL=0.734, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2G33bXflRM0 for ; Tue, 14 Aug 2007 05:16:23 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 40F75142215 for ; Tue, 14 Aug 2007 05:16:23 -0700 (PDT)
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Aug 2007 14:16:23 +0200
X-IronPort-AV: i="4.19,259,1183327200"; d="scan'208"; a="150551912:sNHT43755280"
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7ECGMa2015483; Tue, 14 Aug 2007 14:16:22 +0200
Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp272.cisco.com [10.61.65.16]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7ECGMx0019519; Tue, 14 Aug 2007 12:16:22 GMT
Message-ID: <46C19D10.906@cisco.com>
Date: Tue, 14 Aug 2007 14:16:16 +0200
From: Eliot Lear
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Jonathan Lennox
Subject: Re: [Ietf-calsify] One more 2445bis WGLC comment: DTSTART matching "pattern of the recurrence rule"
References: <46BC1263.5040002@cisco.com> <18112.39469.783367.197741@cnr.cs.columbia.edu>
In-Reply-To: <18112.39469.783367.197741@cnr.cs.columbia.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=984; t=1187093782; x=1187957782; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-calsify]=20One=20more=202445bis=20WGLC=20commen t=3A=20DTSTART=20matching=0A=20=22pattern=20of=20the=20recurrence=20rule=2 2 |Sender:=20; bh=JRMx7cKt3Iw04t3YPPV2i3J/WpMTFq2iEQK2c27Dles=; b=phKGhUQiV3IS+hLvSupyW0mUjcC37+j/NYTn5jRGaJYJlDa/uunQFzvAR8/ZMamydzlAKRi5 1GOjxvMW+gvcPGVHSUZmfvUjG2AUklgrnjzA4MjooFXsknlTQEYp2rXw;
Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; );
Cc: "ietf-calsify@osafoundation.org"
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Aug 2007 12:17:22 -0000
Jonathan Lennox wrote:
> There's one other comment I had that Bernard asked me about at the Chicago
> IETF.
>
> The section on RRULE says that
>
> The "DTSTART" property
> value SHOULD match the pattern of the recurrence rule, if
> specified. The recurrence set generated with a "DTSTART" property
> value that doesn't match the pattern of the rule is undefined.
>
> (For some reason I don't understand, this text also appears in the RDATE and
> EXDATE sections, but leave that aside for now.)
>
> The question is whether the DTSTART can match "the pattern of the recurrence
> rule" if the rule specifies BYSETPOS values not including the value 1. If
> "the pattern" has its obvious definition, I think that it can't.
>
> The obvious fix would be to change the above to
>
> The "DTSTART" property value SHOULD match the pattern of the recurrence
> rule (not including any BYSETPOS value), if specified.
>
>
Substantial.
Return-Path:
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 603C280397 for ; Tue, 14 Aug 2007 05:16:51 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 75357142219 for ; Tue, 14 Aug 2007 05:15:56 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.725
X-Spam-Level:
X-Spam-Status: No, score=-1.725 tagged_above=-50 required=4 tests=[AWL=0.740, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdAOd3mrdwzL for ; Tue, 14 Aug 2007 05:15:53 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 640AD142215 for ; Tue, 14 Aug 2007 05:15:53 -0700 (PDT)
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Aug 2007 14:15:52 +0200
X-IronPort-AV: i="4.19,259,1183327200"; d="scan'208"; a="150551867:sNHT3246214700"
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7ECFoS7015331; Tue, 14 Aug 2007 14:15:50 +0200
Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp272.cisco.com [10.61.65.16]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7ECFox0019305; Tue, 14 Aug 2007 12:15:50 GMT
Message-ID: <46C19CF0.1070201@cisco.com>
Date: Tue, 14 Aug 2007 14:15:44 +0200
From: Eliot Lear
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Jonathan Lennox
Subject: Re: [Ietf-calsify] One last comment on exact vs. nominal durations
References: <46BC1263.5040002@cisco.com> <18112.33287.205615.836886@cnr.cs.columbia.edu>
In-Reply-To: <18112.33287.205615.836886@cnr.cs.columbia.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=759; t=1187093750; x=1187957750; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-calsify]=20One=20last=20comment=20on=20exact=20 vs.=20nominal=20durations |Sender:=20; bh=WVx4/b8SBrVSJxTocmB+MiKXPSyKIZOAjrQveHtkidg=; b=lgOala45SIMonYRGKYo/D+z0qzfHBlsnHk16qMJ+r5pINTSlStBp3ER8D8fjvpxd0Rm+7ab0 rDp5tFjhWvDSBtmQETK5IitNlkjShwzIioGs7kCsCFHFzyR26TEoFCV5;
Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; );
Cc: "ietf-calsify@osafoundation.org"
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Aug 2007 12:16:51 -0000
Jonathan Lennox wrote:
> One other issue occured to me on exact vs. nominal durations.
>
> The definition of RRULE says:
>
> If the duration of the recurring component is specified with the
> "DTEND" or "DUE" property, then the same exact duration will apply
> to all the members of the generated recurrence set.
>
> This is correct for DTEND or DUE specified with VALUE=DATE-TIME, but I think
> it's wrong for DTEND or DUE (and thus also DTSTART) with VALUE=DATE. In
> this latter case, I think it's clear that the desired outcome is always
> for the event to last a nominal number of days, not the exact duration of
> time of the first instance of the recurrence set.
>
> Is this worth addressing?
>
>
Substantial
Return-Path:
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B807280397 for ; Tue, 14 Aug 2007 05:15:09 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CAF54142215 for ; Tue, 14 Aug 2007 05:14:14 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.719
X-Spam-Level:
X-Spam-Status: No, score=-1.719 tagged_above=-50 required=4 tests=[AWL=0.746, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fANhWQBPRE7z for ; Tue, 14 Aug 2007 05:14:11 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6E045142219 for ; Tue, 14 Aug 2007 05:14:11 -0700 (PDT)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Aug 2007 14:14:11 +0200
X-IronPort-AV: i="4.19,259,1183327200"; d="scan'208"; a="150551723:sNHT958322418"
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7ECEAFJ026819; Tue, 14 Aug 2007 14:14:10 +0200
Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp272.cisco.com [10.61.65.16]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7ECE9x0018672; Tue, 14 Aug 2007 12:14:09 GMT
Message-ID: <46C19C8A.2040803@cisco.com>
Date: Tue, 14 Aug 2007 14:14:02 +0200
From: Eliot Lear
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Jonathan Lennox
Subject: Re: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07 ends TODAY
References: <46BC1263.5040002@cisco.com> <18112.32568.616017.127025@cnr.cs.columbia.edu>
In-Reply-To: <18112.32568.616017.127025@cnr.cs.columbia.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2941; t=1187093650; x=1187957650; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-calsify]=20Reminder=3A=20WGLC=20for=20draft-iet f-calsify-rfc2445bis-07=0A=20ends=20TODAY |Sender:=20; bh=zIKXLKsSsrPQ3Xh5GjfenZx9Ot3KWD/MT8X0cjHh884=; b=VJpy6NcHCZYYVyksxhGTbmVcMuPWRnHbVNx/NwIpFqNbwQP/NF0ezcMOWmOazaAMncPy8hgG bXWqmqrEOOSS6aoOycJaCQcD80UYmEKBpiOTlxgP562n8cCRiLWqBauC;
Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; );
Cc: "ietf-calsify@osafoundation.org"
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Aug 2007 12:15:09 -0000
Jonathan,
Thank you for your comments. So long as there are no objections I see
no reason not to include them as part of last call comments. Let's just
go through this set as I did the others.
Please see below.
Jonathan Lennox wrote:
> I'm very sorry -- I should have sent these comments earlier. (I was sick on
> Friday, and did not see the reminder e-mail until this morning.)
>
>
> I have several comments on section 3.3.6 (DURATION).
>
> First of all, one of the items in the text I sent in May (in the message
> )
> didn't get applied to this draft; I think it's uncontroversial but a fairly
> important corner case.
>
> Add the text (wordsmithing as appropriate):
>
> + If the local time when a nominal duration would end does not exist,
> + or occurs more than once, in the duration's timezone, it is
> + interpreted in the same manner as an explicit DATE-TIME value
> + describing that date and time, as specified in section 3.3.5.
>
Substantial.
>
> Editorially, this section has the problem that it uses the terms "nominal
> duration", "accurate duration", and "exact duration" without defining them.
> The definitions can be semi-inferred from context, but I'd be curious if
> someone who hasn't wrestled with these issues as much as I have can
> understand the text.
>
>
> I also think that the discussion of adding weeks, days, hours, minutes, and
> seconds in that strict order -- when actually all that matters is that
> nominal durations (weeks + days) be added before accurate durations (hours,
> minutes, and seconds) -- is confusing; it leads the reader to think there's
> some significance to the order of the arithmetic operations within each section.
>
>
> I have two spelling/grammar fixes in this section as well:
>
> The duration of a week or a day depends on its position in the
> calendar. In the case of discontinuities in the time scale, such
> as the change from standard time to daylight time and back, the
> - computation of the exact duration requires the substraction or
> + computation of the exact duration requires the subtraction or
> addition of the change of duration of the discontinuity. Leap
> seconds MUST NOT be considered when computing an exact duration.
>
Editorial.
> ...
>
> No additional content value encoding (i.e., BACKSLASH character
> - encoding) are defined for this value type.
> + encoding) is defined for this value type.
>
Editorial.
>
>
> The one other stylistic comment I'd make on the changes introduced in
> version -07 is that it's not usually appropriate to use contractions
> ("don't", "doesn't", etc.) in formal standards writing. These should be
> expanded to "do not", "does not", etc.
>
Editorial.
Eliot
Return-Path:
X-Original-To: Ietf-calsify@osafoundation.org
Delivered-To: Ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C319980609 for ; Mon, 13 Aug 2007 15:44:18 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D8291142210 for ; Mon, 13 Aug 2007 15:43:23 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -0.055
X-Spam-Level:
X-Spam-Status: No, score=-0.055 tagged_above=-50 required=4 tests=[AWL=-0.556, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_ID=1.393]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WDjdxZuOBiQ for ; Mon, 13 Aug 2007 15:43:22 -0700 (PDT)
Received: from alnrmhc13.comcast.net (alnrmhc13.comcast.net [204.127.225.93]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5C382142211 for ; Mon, 13 Aug 2007 15:43:22 -0700 (PDT)
Received: from thare (c-71-203-100-120.hsd1.wa.comcast.net[71.203.100.120]) by comcast.net (alnrmhc13) with SMTP id <20070813224321b1300edc33e>; Mon, 13 Aug 2007 22:43:21 +0000
From: "Tim Hare"
To: "'Eliot Lear'" , "'CALSIFY Mailinglist'"
Subject: RE: [Ietf-calsify] A question inspired by Eliot's e-mail
Date: Mon, 13 Aug 2007 18:43:19 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <46C033F0.6010203@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
Thread-Index: AcfdlbUBKU/JSgwBQqOfyNTnaDyRBAAZQANA
Message-Id: <20070813224322.5C382142211@laweleka.osafoundation.org>
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Aug 2007 22:44:18 -0000
Specifically, these statements:
"While some might view this as substantial, I believe this is editorial
because the working group discussed the intent here in depth, and Nigel is
correct in my opinion as to our interpretation."
Interpretation of intent was one of the things we used to have long
discussions about on previous calendar lists, related to the original RFCs.
So, I'm inspired to ask: how will we judge if we have, in fact, simplified
things and improved interoperability? Is there any forum where we could get
the input of vendors and developers on that topic?
Note that this is NOT an opinion on the RFC itself, one way or another.
Tim Hare
Interested Bystander, Non-Inc.
Return-Path:
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7CE2B8082A for ; Mon, 13 Aug 2007 10:52:40 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 93671142210 for ; Mon, 13 Aug 2007 10:51:45 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.189
X-Spam-Level:
X-Spam-Status: No, score=-1.189 tagged_above=-50 required=4 tests=[AWL=1.411, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmW-CSeY75Um for ; Mon, 13 Aug 2007 10:51:43 -0700 (PDT)
Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8DCF614220E for ; Mon, 13 Aug 2007 10:51:43 -0700 (PDT)
Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.6/8.13.6) with ESMTP id l7DHpggl022818 for ; Mon, 13 Aug 2007 13:51:42 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu)
Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.6/8.13.6/Submit) id l7DHpfap022815; Mon, 13 Aug 2007 13:51:41 -0400 (EDT) (envelope-from lennox)
From: Jonathan Lennox
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <18112.39469.783367.197741@cnr.cs.columbia.edu>
Date: Mon, 13 Aug 2007 13:51:41 -0400
To: "ietf-calsify@osafoundation.org"
In-Reply-To: <46BC1263.5040002@cisco.com>
References: <46BC1263.5040002@cisco.com>
X-Mailer: VM 7.19 under Emacs 22.1.1
Subject: [Ietf-calsify] One more 2445bis WGLC comment: DTSTART matching "pattern of the recurrence rule"
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Aug 2007 17:52:40 -0000
There's one other comment I had that Bernard asked me about at the Chicago
IETF.
The section on RRULE says that
The "DTSTART" property
value SHOULD match the pattern of the recurrence rule, if
specified. The recurrence set generated with a "DTSTART" property
value that doesn't match the pattern of the rule is undefined.
(For some reason I don't understand, this text also appears in the RDATE and
EXDATE sections, but leave that aside for now.)
The question is whether the DTSTART can match "the pattern of the recurrence
rule" if the rule specifies BYSETPOS values not including the value 1. If
"the pattern" has its obvious definition, I think that it can't.
The obvious fix would be to change the above to
The "DTSTART" property value SHOULD match the pattern of the recurrence
rule (not including any BYSETPOS value), if specified.
--
Jonathan Lennox
lennox@cs.columbia.edu
Return-Path:
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D8D49807AD for ; Mon, 13 Aug 2007 09:09:39 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EF187142211 for ; Mon, 13 Aug 2007 09:08:44 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.114
X-Spam-Level:
X-Spam-Status: No, score=-1.114 tagged_above=-50 required=4 tests=[AWL=1.486, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYjI-S9GAOU6 for ; Mon, 13 Aug 2007 09:08:40 -0700 (PDT)
Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2B44B142209 for ; Mon, 13 Aug 2007 09:08:40 -0700 (PDT)
Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.6/8.13.6) with ESMTP id l7DG8dsI022383 for ; Mon, 13 Aug 2007 12:08:39 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu)
Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.6/8.13.6/Submit) id l7DG8d4O022380; Mon, 13 Aug 2007 12:08:39 -0400 (EDT) (envelope-from lennox)
From: Jonathan Lennox
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <18112.33287.205615.836886@cnr.cs.columbia.edu>
Date: Mon, 13 Aug 2007 12:08:39 -0400
To: "ietf-calsify@osafoundation.org"
In-Reply-To: <46BC1263.5040002@cisco.com>
References: <46BC1263.5040002@cisco.com>
X-Mailer: VM 7.19 under Emacs 22.1.1
Subject: [Ietf-calsify] One last comment on exact vs. nominal durations
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Aug 2007 16:09:40 -0000
One other issue occured to me on exact vs. nominal durations.
The definition of RRULE says:
If the duration of the recurring component is specified with the
"DTEND" or "DUE" property, then the same exact duration will apply
to all the members of the generated recurrence set.
This is correct for DTEND or DUE specified with VALUE=DATE-TIME, but I think
it's wrong for DTEND or DUE (and thus also DTSTART) with VALUE=DATE. In
this latter case, I think it's clear that the desired outcome is always
for the event to last a nominal number of days, not the exact duration of
time of the first instance of the recurrence set.
Is this worth addressing?
--
Jonathan Lennox
lennox@cs.columbia.edu
Return-Path:
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8481F7F9EA for ; Mon, 13 Aug 2007 08:57:39 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 98E68142211 for ; Mon, 13 Aug 2007 08:56:44 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.032
X-Spam-Level:
X-Spam-Status: No, score=-1.032 tagged_above=-50 required=4 tests=[AWL=1.568, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtlvhXZ3oeep for ; Mon, 13 Aug 2007 08:56:42 -0700 (PDT)
Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5ABEB142210 for ; Mon, 13 Aug 2007 08:56:42 -0700 (PDT)
Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.6/8.13.6) with ESMTP id l7DFuf5w022295 for ; Mon, 13 Aug 2007 11:56:41 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu)
Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.6/8.13.6/Submit) id l7DFuex9022292; Mon, 13 Aug 2007 11:56:40 -0400 (EDT) (envelope-from lennox)
From: Jonathan Lennox
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <18112.32568.616017.127025@cnr.cs.columbia.edu>
Date: Mon, 13 Aug 2007 11:56:40 -0400
To: "ietf-calsify@osafoundation.org"
Subject: Re: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07 ends TODAY
In-Reply-To: <46BC1263.5040002@cisco.com>
References: <46BC1263.5040002@cisco.com>
X-Mailer: VM 7.19 under Emacs 22.1.1
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Aug 2007 15:57:39 -0000
I'm very sorry -- I should have sent these comments earlier. (I was sick on
Friday, and did not see the reminder e-mail until this morning.)
I have several comments on section 3.3.6 (DURATION).
First of all, one of the items in the text I sent in May (in the message
)
didn't get applied to this draft; I think it's uncontroversial but a fairly
important corner case.
Add the text (wordsmithing as appropriate):
+ If the local time when a nominal duration would end does not exist,
+ or occurs more than once, in the duration's timezone, it is
+ interpreted in the same manner as an explicit DATE-TIME value
+ describing that date and time, as specified in section 3.3.5.
Editorially, this section has the problem that it uses the terms "nominal
duration", "accurate duration", and "exact duration" without defining them.
The definitions can be semi-inferred from context, but I'd be curious if
someone who hasn't wrestled with these issues as much as I have can
understand the text.
I also think that the discussion of adding weeks, days, hours, minutes, and
seconds in that strict order -- when actually all that matters is that
nominal durations (weeks + days) be added before accurate durations (hours,
minutes, and seconds) -- is confusing; it leads the reader to think there's
some significance to the order of the arithmetic operations within each section.
I have two spelling/grammar fixes in this section as well:
The duration of a week or a day depends on its position in the
calendar. In the case of discontinuities in the time scale, such
as the change from standard time to daylight time and back, the
- computation of the exact duration requires the substraction or
+ computation of the exact duration requires the subtraction or
addition of the change of duration of the discontinuity. Leap
seconds MUST NOT be considered when computing an exact duration.
...
No additional content value encoding (i.e., BACKSLASH character
- encoding) are defined for this value type.
+ encoding) is defined for this value type.
The one other stylistic comment I'd make on the changes introduced in
version -07 is that it's not usually appropriate to use contractions
("don't", "doesn't", etc.) in formal standards writing. These should be
expanded to "do not", "does not", etc.
--
Jonathan Lennox
lennox@cs.columbia.edu
Return-Path:
X-Original-To: Ietf-calsify@osafoundation.org
Delivered-To: Ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EABA17FFC4 for ; Mon, 13 Aug 2007 03:36:38 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0F26B142212 for ; Mon, 13 Aug 2007 03:35:44 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.708
X-Spam-Level:
X-Spam-Status: No, score=-1.708 tagged_above=-50 required=4 tests=[AWL=0.757, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXMcDSP8fniZ for ; Mon, 13 Aug 2007 03:35:41 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3B7CB142210 for ; Mon, 13 Aug 2007 03:35:40 -0700 (PDT)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Aug 2007 12:35:39 +0200
X-IronPort-AV: i="4.19,254,1183327200"; d="scan'208"; a="150450690:sNHT71361208"
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7DAZdDu003375 for ; Mon, 13 Aug 2007 12:35:39 +0200
Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp87.cisco.com [10.61.64.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7DAZcx0014385 for ; Mon, 13 Aug 2007 10:35:38 GMT
Message-ID: <46C033F0.6010203@cisco.com>
Date: Mon, 13 Aug 2007 12:35:28 +0200
From: Eliot Lear
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: CALSIFY Mailinglist
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15941; t=1187001339; x=1187865339; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20working=20group=20last=20call=20comments=20for=20draft-ietf-c alsify-rfc2445bis-07.txt |Sender:=20; bh=sjTsxyumRyxSYsocpjut/NLi472htKCaQre+lRlbJ/k=; b=LLgiQiYkBJpKyp5s6Tlim4osGdJBoRySIxgHlYeB2H0Joq+4it9olDfksRaIZePjT9iZlA9q C/wrv/of017W/lyY1ufg+hgbCdoZgjDJIRDMiHnV7aKadD3qzyuHF/aQ;
Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; );
Subject: [Ietf-calsify] working group last call comments for draft-ietf-calsify-rfc2445bis-07.txt
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Aug 2007 10:36:39 -0000
Dear all,
Working Group Last Call (WGLC) has now closed for
draft-ietf-calsify-rfc2445bis-07.txt. We received two messages during
WGLC. There are two forms of comments we will address: editorial and
substantial changes. The editor may use his discretion accept or reject
editorial comments. The working group must consider proposals for
substantial changes. What follows is the chair's opinion as to what is
editorial and what is substantial:
On the 3rd of August, Bernard proposed a change to close Issue 63. I
view this change as substantial and requiring working group input.
Now, breaking up Nigel Swinson's message of the 1st of August (thank
you, Nigel):
> Version 7 contains numerous additions of this form:
>
> "Applications MUST treat x-name and iana-token value they don't
> recognized the same way as the XXXX value."
>
> I don't think this is gramatically correct. I'd suggest:
>
> "Applications MUST treat x-name and iana-token values they don't
> recognize the same way as they would the XXXX value."
>
Editorial.
> Or better still rely on the existing description of what the default value
> is:
>
> "Applications MUST ignore x-name and iana-token values they don't
> recognize and revert to the default value for the parameter."
>
Substantial if reverting means changing the actual text of the invitation.
> This comment applies to:
> - 3.2. Property Parameters
> - 3.2.3. Calendar User Type
> - 3.2.9. Free/Busy Time Type
> - 3.2.12. Participation Status
> - 3.2.14. Relationship Type
> - 3.2.15. Participation Role
> - 3.2.19. Value Data Types
> - 3.8.1.3. Classification
> - 3.8.6.1. Action
>
> 3.3.10. Recurrence Rule
>
> The UNTIL rule part defines a DATE or DATE-TIME value which bounds
> the recurrence rule in an inclusive manner. If the value
> specified by UNTIL is synchronized with the specified recurrence,
> this DATE or DATE-TIME becomes the last instance of the
> recurrence. The value of the UNTIL rule part MUST have the same
> value type as the "DTSTART" property. Furthermore, if the
> "DTSTART" property is specified as a date with local time, then
> the UNTIL rule part MUST also be specified as a date with local
> - time. Else, if the "DTSTART" property is specified as a date with
> + time. If the "DTSTART" property is specified as a date with
>
Editorial.
> UTC time or a date with local time and time zone reference, then
> the UNTIL rule part MUST be specified as a date with UTC time. In
> the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
> - rule part MUST always be specified as a date with UTC time. If
> - specified as a DATE-TIME value, then it MUST be specified in a UTC
> - time format. If not present, and the COUNT rule part is also not
> + rule part MUST always be specified as a date with UTC time, with the
> + "DTSTART" always represented as a date with local time. If the UNTIL
> + and COUNT rule parts are not
>
Substantial.
> present, the "RRULE" is considered to repeat forever.
>
> Below I've re-ordered the sentences in addition to changing one word. I
> find changing from "the specific day" to "a specific day" helpful in warning
> that 3MO in a yearly rule isn't necessarily "the 3rd Monday in the year" and
> rather "a 3rd Monday in the year". Later we go on to describe in more
> detail how to interpret "a 3rd Monday in the year".
>
> Each BYDAY value can also be preceded by a positive (+n) or
> negative (-n) integer. If present, this indicates the nth
> - occurrence of the specific day within the MONTHLY or YEARLY
> + occurrence of a specific day within the MONTHLY or YEARLY
> "RRULE". For example, within a MONTHLY rule, +1MO (or simply 1MO)
> represents the first Monday within the month, whereas -1MO
> - represents the last Monday of the month. If an integer modifier
> + represents the last Monday of the month. The
> + numeric value in a BYDAY rule part with the FREQ rule part set to
> + YEARLY corresponds to an offset within the month when the BYMONTH
> + rule part is present, and corresponds to an offset within the year
> + when the BYWEEKNO or BYMONTH rule parts are present.
> + If an integer modifier
>
This seems to be editorial.
> is not present, it means all days of this type within the
> specified frequency. For example, within a MONTHLY rule, MO
> represents all Mondays within the month. The BYDAY rule part MUST
> NOT be specified with a numeric value when the FREQ rule part is
> not set to MONTHLY or YEARLY. Furthermore, the BYDAY rule part
> MUST NOT be specified with a numeric value with the FREQ rule part
> + set to YEARLY when the BYWEEKNO rule part is specified.
> - set to YEARLY when the BYWEEKNO rule part is specified. The
> - numeric value in a BYDAY rule part with the FREQ rule part set to
> - YEARLY corresponds to an offset within the month when the BYMONTH
> - rule part is present, and corresponds to an offset within the year
> - when the BYWEEKNO or BYMONTH rule parts are present.
>
>
Again, editorial.
> The BYYEARDAY rule part specifies a COMMA character (US-ASCII
> decimal 44) separated list of days of the year. Valid values are
> 1 to 366 or -366 to -1. For example, -1 represents the last day
> of the year (December 31st) and -306 represents the 306th to the
> last day of the year (March 1st). The BYYEARDAY rule part MUST
> NOT be specified when the FREQ rule part is set to DAILY, WEEKLY,
> - and MONTHLY.
> + or MONTHLY.
>
While some might view this as substantial, I believe this is editorial
because the working group discussed the intent here in depth, and Nigel
is correct in my opinion as to our interpretation.
> I think there's too many negatives in what was there:
>
> The BYWEEKNO rule part specifies a COMMA character (US-ASCII
> decimal 44) separated list of ordinals specifying weeks of the
> year. Valid values are 1 to 53 or -53 to -1. This corresponds to
> weeks according to week numbering as defined in [ISO.8601.2004].
> A week is defined as a seven day period, starting on the day of
> the week defined to be the week start (see WKST). Week number one
> of the calendar year is the first week which contains at least
> four (4) days in that calendar year. This rule part MUST NOT be
> - used when the FREQ rule part is not set to YEARLY. For example, 3
> + used when the FREQ rule part is set to anything other than YEARLY.
> + For example, 3
>
Editorial.
> represents the third week of the year.
>
> WRT to the text below I think we should either:
> - Say BYSETPOS is only valid with Weekly, Monthly, Yearly rules,
> - Specify what the "interval" for daily, hourly, minutely, secondly means.
> - Drop the new text, as I think the example is sufficient illustration.
> - Change the example to illustrate what obscurity it was that lead to the
> need for the new text.
>
> My vote would be to drop some of the new text to become:
>
> The BYSETPOS rule part specifies a COMMA character (US-ASCII
> decimal 44) separated list of values which corresponds to the nth
> occurrence within the set of recurrence instances specified by the
> rule. BYSETPOS operates on a set of recurrence instances in one
> - interval of the recurrence rule. For a WEEKLY rule, the interval
> - is one week, for a MONTHLY rule, one month, and for a YEARLY rule,
> - one year. Valid values are 1 to 366 or -366 to -1. It MUST only
> + interval of the recurrence rule.
> + Valid values are 1 to 366 or -366 to -1. It MUST only
> be used in conjunction with another BYxxx rule part. For example
> "the last work day of the month" could be represented as:
>
Substantial.
> FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
>
> Each BYSETPOS value can include a positive (+n) or negative (-n)
> integer. If present, this indicates the nth occurrence of the
> specific occurrence within the set of occurences specified by the
> rule.
>
> The phrase "special expand" is mentioned nowhere else in the document. I
> think the concept was better expressed by my suggestion from the 29th May.
> You merge the "Expand" cells in the Yearly/Monthly columns to illustrate
> that each creates a set, and when taken together it's the union of the sets.
> Also even with a numeric modifier on ByDay, it's still the case that
> Monthly/Yearly + BYDAY will expand, and while it's true that numeric
> modifiers on ByDay with yearly rules requires attention, I think it's
> adequately dealt with in the paragraphs above on ByDay. So I'd make it:
>
> - BYDAY has some special behaviour depending on the FREQ value and
> - this is described in separate notes below the table.
>
> +----------+--------+--------+-------+-------+------+-------+------+
> | |SECONDLY|MINUTELY|HOURLY |DAILY |WEEKLY|MONTHLY|YEARLY|
> +----------+--------+--------+-------+-------+------+-------+------+
> - |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit |Expand|
> - +----------+--------+--------+-------+-------+------+-------+------+
> - |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A |Expand|
> - +----------+--------+--------+-------+-------+------+-------+------+
> - |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand|
> - +----------+--------+--------+-------+-------+------+-------+------+
> - |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A |Expand |Expand|
> - +----------+--------+--------+-------+-------+------+-------+------+
> - |BYDAY |Limit |Limit |Limit |Limit |Expand|Note 1 |Note 2|
> - +----------+--------+--------+-------+-------+------+-------+------+
> + |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit | |
> + +----------+--------+--------+-------+-------+------+-------+ +
> + |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A | |
> + +----------+--------+--------+-------+-------+------+-------+ +
> + |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand|
> + +----------+--------+--------+-------+-------+------+-------+ +
> + |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A | | |
> + +----------+--------+--------+-------+-------+------+Expand + +
> + |BYDAY |Limit |Limit |Limit |Limit |Expand| | |
> + +----------+--------+--------+-------+-------+------+-------+------+
> |BYHOUR |Limit |Limit |Limit |Expand |Expand|Expand |Expand|
> +----------+--------+--------+-------+-------+------+-------+------+
> |BYMINUTE |Limit |Limit |Expand |Expand |Expand|Expand |Expand|
> +----------+--------+--------+-------+-------+------+-------+------+
> |BYSECOND |Limit |Expand |Expand |Expand |Expand|Expand |Expand|
> +----------+--------+--------+-------+-------+------+-------+------+
> |BYSETPOS |Limit |Limit |Limit |Limit |Limit |Limit |Limit |
> +----------+--------+--------+-------+-------+------+-------+------+
>
> - Note 1: Limit if BYMONTHDAY is present, otherwise special expand
> - for MONTHLY.
> -
> - Note 2: Limit if BYYEARDAY or BYMONTHDAY is present, otherwise
> - special expand for WEEKLY if BYWEEKNO present, otherwise
> - special expand for MONTHLY if BYMONTH present, otherwise
> - special expand for YEARLY.
>
> + In YEARLY rules, BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY and BYDAY
> work
> + together to expand the recurrence set. Each on their own will
> specify
> + a range of valid instances, and when used in combination it is the
> union
> + of all ranges that create the required recurrence set. So for
> example
> + in a YEARLY rule BYDAY=MO will mean every Monday, and BYMONTHDAY=1
> will
> + mean the first of every month, so when used together they mean the
> first of
> + every month, but only when it's a Monday. It would not mean on the
> first
> + of every month and also on every Monday. Likewise in MONTHLY rules,
> + BYMONTHDAY and BYDAY work together to expand the recurrence set.
>
Substantial and editorial. The combining of boxes is editorial.
> 3.6. Calendar Components
>
> An iCalendar object MUST include the "PRODID" and "VERSION" calendar
> properties. In addition, it MUST include at least one calendar
> component. Special forms of iCalendar objects are possible to
> publish just busy time (i.e., only a "VFREEBUSY" calendar component)
> or time zone (i.e., only a "VTIMEZONE" calendar component)
> information. In addition, a complex iCalendar object that is used to
> capture a complete snapshot of the contents of a calendar is possible
> (e.g., composite of many different calendar components). More
> commonly, an iCalendar object will consist of just a single "VEVENT",
> "VTODO" or "VJOURNAL" calendar component. Applications MUST ignore
> - x-comp and iana-comp they don't recognized.
> + x-comp and iana-comp they don't recognize.
>
Editorial.
> 3.8.1.1. Attachment
>
> Conformance: This property can be specified multiple times in a
> "VEVENT", "VTODO", "VJOURNAL" or "VALARM" calendar component with
> - the exception of AUDIO alarm which only allow this property to
> + the exception of AUDIO alarm which only allows this property to
> occur once.
>
Editorial.
> 3.8.2.3. Date/Time Due
>
> - Description: This property defines the date and time that a to-do is
> + Description: This property defines the date and time before which a
>
Editorial.
> to-do is
> expected to be completed. For cases where this property is
> specified in a "VTODO" calendar component that also specifies a
> "DTSTART" property, the value type of this property MUST be the
> same as the "DTSTART" property, and the value of this property
> MUST be later in time than the value of the "DTSTART" property.
> Furthermore, this property MUST be specified as a date with local
> time if and only if the "DTSTART" property is also specified as a
> date with local time.
>
> 3.8.6.2. Repeat Count
> - Description: This property defines the number of time an alarm
> + Description: This property defines the number of times an alarm
>
Editorial.
> should be repeated after its initial trigger. If the alarm
> triggers more than once, then this property MUST be specified
> along with the "DURATION" property.
>
> 3.8.7.2. Date/Time Stamp
>
> In the case of an iCalendar object that specifies a "METHOD"
> - property, this property is different than the "CREATED" and "LAST-
> + property, this property is different to the "CREATED" and "LAST-
>
Editorial. Suggestion: "this property differs from".
> MODIFIED" properties. These two properties are used to specify
> when the particular calendar data in the calendar store was
> created and last modified. This is different than when the
> iCalendar object representation of the calendar service
> information was created or last modified.
>
> Cheers,
>
> Nigel
>
>
Thanks again,
Eliot
Return-Path:
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E5EF68084A for ; Fri, 10 Aug 2007 00:24:31 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0C6C114220A for ; Fri, 10 Aug 2007 00:23:37 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.69
X-Spam-Level:
X-Spam-Status: No, score=-1.69 tagged_above=-50 required=4 tests=[AWL=0.775, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lbFbRZDbTiX for ; Fri, 10 Aug 2007 00:23:35 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1F436142207 for ; Fri, 10 Aug 2007 00:23:34 -0700 (PDT)
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Aug 2007 09:23:35 +0200
X-IronPort-AV: i="4.19,244,1183327200"; d="scan'208"; a="150254482:sNHT77556446"
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7A7NXi2031394 for ; Fri, 10 Aug 2007 09:23:33 +0200
Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp4278.cisco.com [10.61.80.181]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7A7NXx0020382 for ; Fri, 10 Aug 2007 07:23:33 GMT
Message-ID: <46BC1263.5040002@cisco.com>
Date: Fri, 10 Aug 2007 09:23:15 +0200
From: Eliot Lear
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: "ietf-calsify@osafoundation.org"
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=60; t=1186730613; x=1187594613; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Reminder=3A=20WGLC=20for=20draft-ietf-calsify-rfc2445bis-07=2 0ends=20TODAY |Sender:=20; bh=NtXI3aKUibPMKUxZPy8QY4xrjcCAp/VmJWucHcmyEpA=; b=d6exmN0Ej7esWjw8+/vU0x7BC/Ytw8JkhZphhcLwP+WC7FmnHYqm7cvwH89aAUjV8EIA1elx eDePiFjY4d6qkc4nNXkDu3QHyX84dGXmzPoYPQJI/mGNgscEoW3FY5yp;
Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; );
Subject: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07 ends TODAY
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 10 Aug 2007 07:24:32 -0000
Please send your comments to the list.
Thanks,
Eliot
Return-Path:
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 726997FA6D for ; Wed, 8 Aug 2007 14:02:57 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 889F7142201 for ; Wed, 8 Aug 2007 14:02:02 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.484
X-Spam-Level:
X-Spam-Status: No, score=-1.484 tagged_above=-50 required=4 tests=[AWL=-0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_FAIL=1.142]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBcQVykQ0xxC for ; Wed, 8 Aug 2007 14:02:00 -0700 (PDT)
Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3E6FA1421FD for ; Wed, 8 Aug 2007 14:01:59 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v752.3)
To: Calsify WG
Message-Id: <8C18814C-F9C4-4606-B630-2AFAB349F880@osafoundation.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-19--6196072
References:
From: Lisa Dusseault
Date: Wed, 8 Aug 2007 14:01:57 -0700
X-Mailer: Apple Mail (2.752.3)
Subject: [Ietf-calsify] Fwd: Review of media type form before submission to IANA - knowledgeitem
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: