Subject: [Ietf-calsify] Reminder: CalConnect vCard Workshop - September 18, 2007 - Cambridge, Massachusetts

From: Dave.Thewlis at calconnect.org (Dave Thewlis)
Date: Wed Aug 29 09:41:22 2007

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 <http://www.calconnect.org/vcardreg.shtml> and 
logistics <http://www.calconnect.org/vcardworkshoplogistics.shtml> 
pages, a general discussion list 
<http://www.calconnect.org/vcardworkshoplist.shtml> about the workshop, 
and a questionnaire <http://www.calconnect.org/vcardquestionnaire.shtml> 
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 <http://www.calconnect.org/roundtable10.shtml> 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 
<http://www.calconnect.org/vcardquestionnaire.shtml>, 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 ? [email-masked] 
<mailto:[email-masked]>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070829/0fb70d5c/attachment.html

Date: Wed, 29 Aug 2007 09:40:10 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify]  Reminder: CalConnect vCard Workshop - September 18, 2007 - Cambridge,  Massachusetts
Reply-To: [email-masked]

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 <http://www.calconnect.org/vcardreg.shtml> and 
logistics <http://www.calconnect.org/vcardworkshoplogistics.shtml> 
pages, a general discussion list 
<http://www.calconnect.org/vcardworkshoplist.shtml> about the workshop, 
and a questionnaire <http://www.calconnect.org/vcardquestionnaire.shtml> 
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 <http://www.calconnect.org/roundtable10.shtml> 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 
<http://www.calconnect.org/vcardquestionnaire.shtml>, 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 · [email-masked] 
<mailto:[email-masked]>

--------------070307060708020106080606
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Reminder:&nbsp; The CalConnect vCard Workshop is coming up on Tuesday,
September 18th, at M.I.T. in Cambridge.<br>
<br>
---<br>
<br>
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 <u>open</u> to vendors,
customers, CalConnect members and non-members alike. There is no fee,
but you <u>must</u> register in advance and numbers are limited.
Please see <br>
<a href="http://www.calconnect.org/vcardworkshop.shtml">http://www.calconnect.org/vcardworkshop.shtml</a>
for more information and links to the <a
 href="http://www.calconnect.org/vcardreg.shtml">registration</a> and <a
 href="http://www.calconnect.org/vcardworkshoplogistics.shtml">logistics</a>
pages, a general <a
 href="http://www.calconnect.org/vcardworkshoplist.shtml">discussion
list</a> about the workshop, and a <a
 href="http://www.calconnect.org/vcardquestionnaire.shtml">questionnaire</a>
to give us more guidance to make the workshop as productive as possible.<br>
<br>
&gt;From the workshop introduction page:<br>
<br>
<font color="#330099"><small>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 &amp; 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.<br>
<br>
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.<br>
<br>
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.</small></font><br>
<br>
<br>
If you are not a CalConnect member, this is also an opportunity to stay
on for <a href="http://www.calconnect.org/roundtable10.shtml">Roundtable
X</a> as an observer, and we'd be delighted to have you; you will have
to register separately for the Roundtable.&nbsp; <br>
<br>
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 <a
 href="http://www.calconnect.org/vcardquestionnaire.shtml">questionnaire</a>,
as this will help provide the workshop participants with guidance as to
the directions any progression on vCard should take.<br>
<br>
<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------070307060708020106080606--

Date: Wed, 29 Aug 2007 09:36:34 -0700
From: "David C. Thewlis" <[email-masked]>
Organization: DCTA Inc.
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Quick Reminder: CalConnect Roundtable X and Interoperability Test Event -September 17-21, Cambridge, Massachusetts
Reply-To: [email-masked], [email-masked]

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 · [email-masked] 
<mailto:[email-masked]>

--------------040601040008090209010903
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
A quick reminder that the CalConnect Roundtable and IOP test&nbsp; event is
only about three weeks away, and the registration fee for the
Roundtable goes up (a little) after September 3rd.&nbsp; Hotels rooms appear
to have become predictably scarce, but don't let that dissuade you.&nbsp; We
hope to see you at M.I.T.!<b><br>
</b><br>
Logistics and registration information may be found at <a
 href="http://www.calconnect.org/roundtable10.shtml">http://www.calconnect.org/roundtable10.shtml</a>
and at <a href="http://www.calconnect.org/iopseptember2007.shtml">http://www.calconnect.org/iopseptember2007.shtml</a><br>
<br>
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 <a
 href="http://www.calconnect.org/observer.shtml">http://www.calconnect.org/observer.shtml</a>
for more information.<br>
<br>
<br>
Dave Thewlis<br>
<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------040601040008090209010903--

Ironport-Content-Filter: send-to-smtp
Date: Sat, 25 Aug 2007 11:27:06 +1200
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: Aki Niemi <[email-masked]>
Subject: Re: [Ietf-calsify] Draft minutes uploaded
Cc: "[email-masked]" <[email-masked]>

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

Date: Fri, 24 Aug 2007 14:33:42 +0300
From: Aki Niemi <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Draft minutes uploaded

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

Date: Tue, 14 Aug 2007 14:16:16 +0200
From: Eliot Lear <[email-masked]>
To: Jonathan Lennox <[email-masked]>
Subject: Re: [Ietf-calsify] One more 2445bis WGLC comment: DTSTART matching "pattern of the recurrence rule"
Cc: "[email-masked]" <[email-masked]>

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.

Date: Tue, 14 Aug 2007 14:15:44 +0200
From: Eliot Lear <[email-masked]>
To: Jonathan Lennox <[email-masked]>
Subject: Re: [Ietf-calsify] One last comment on exact vs. nominal durations
Cc: "[email-masked]" <[email-masked]>

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

Date: Tue, 14 Aug 2007 14:14:02 +0200
From: Eliot Lear <[email-masked]>
To: Jonathan Lennox <[email-masked]>
Subject: Re: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07 ends TODAY
Cc: "[email-masked]" <[email-masked]>

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
> <http://lists.osafoundation.org/pipermail/ietf-calsify/2007-May/001707.html>)
> 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: "Tim Hare" <[email-masked]>
To: "'Eliot Lear'" <[email-masked]>, "'CALSIFY Mailinglist'" <[email-masked]>
Subject: RE: [Ietf-calsify] A question inspired by Eliot's e-mail
Date: Mon, 13 Aug 2007 18:43:19 -0400

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: Jonathan Lennox <[email-masked]>
Date: Mon, 13 Aug 2007 13:51:41 -0400
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] One more 2445bis WGLC comment: DTSTART matching "pattern of the recurrence rule"

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
[email-masked]

From: Jonathan Lennox <[email-masked]>
Date: Mon, 13 Aug 2007 12:08:39 -0400
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] One last comment on exact vs. nominal durations

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
[email-masked]

From: Jonathan Lennox <[email-masked]>
Date: Mon, 13 Aug 2007 11:56:40 -0400
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07 ends TODAY

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
<http://lists.osafoundation.org/pipermail/ietf-calsify/2007-May/001707.html>)
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
[email-masked]

Date: Mon, 13 Aug 2007 12:35:28 +0200
From: Eliot Lear <[email-masked]>
To: CALSIFY Mailinglist <[email-masked]>
Subject: [Ietf-calsify] working group last call comments for draft-ietf-calsify-rfc2445bis-07.txt

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

Date: Fri, 10 Aug 2007 09:23:15 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07 ends TODAY

Please send your comments to the list.

Thanks,

Eliot

To: Calsify WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Wed, 8 Aug 2007 14:01:57 -0700
Subject: [Ietf-calsify] Fwd: Review of media type form before submission to IANA - knowledgeitem

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

FYI -- note the EventML plans

Lisa

Begin forwarded message:

> From: "Jayson Lorenzen" <[email-masked]>
> Date: August 8, 2007 1:15:14 PM PDT
> To: <[email-masked]>
> 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: [email-masked]
>
>
> Author/Change controller:
>
>   Name: Michael Steidl
>
>   E-mail: [email-masked]
>
>

--Apple-Mail-19--6196072
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">FYI -- note the EventML =
plans<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Lisa<BR><DIV><BR><DIV>Begin =
forwarded message:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>From: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">"Jayson Lorenzen" &lt;<A =
href=3D"mailto:[email-masked]">Jayson.Lorenzen@businessw=
ire.com</A>&gt;</FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>Date: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">August 8, 2007 1:15:14 PM =
PDT</FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>To: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">&lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;<=
/FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>Subject: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica"><B>Review of media type form before =
submission to IANA - knowledgeitem</B></FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV> <DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">As per the =
instructions for registering media types based on XML which</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">are outside of the five media types specified in =
rfc3023, and section</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">2.3.1 of rfc 2048. We =
(IPTC) are submitting the following potential</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">media type registration for preliminary community =
review before</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">submission to IANA.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The IPTC =
( <A href=3D"http://www.iptc.org">http://www.iptc.org</A>/ ), is a =
consortium of the world's major</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">news agencies =
and news industry vendors. It develops and maintains</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">technical standards for improved news exchange that =
are used by</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">virtually every major news =
organization in the world.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Currently about 65 companies and =
organisations from the news industry</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">are members =
of the IPTC.<SPAN class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Some of =
the standards currently maintained by IPTC:<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>NewsML 1<SPAN =
class=3D"Apple-converted-space">=A0 =A0 =A0 =A0 =A0 </SPAN><A =
href=3D"http://www.newsml.org">http://www.newsml.org</A>/</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>NITF<SPAN class=3D"Apple-converted-space">=A0 =A0 =A0 =A0 =A0 =A0 =
=A0 </SPAN><A =
href=3D"http://www.nitf.org">http://www.nitf.org</A>/</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>SportsML<SPAN class=3D"Apple-converted-space">=A0 =A0 =A0 =A0 =A0 =
</SPAN><A =
href=3D"http://www.sportsml.org">http://www.sportsml.org</A>/</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-converted-space">=A0 </SPAN>IIM =
<SPAN class=3D"Apple-converted-space">=A0 =A0 =A0 =A0 =A0 =A0 =A0 =
</SPAN><A =
href=3D"http://www.iptc.org/IIM/">http://www.iptc.org/IIM/</A></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>IPTC 7901 (ANPA)<SPAN class=3D"Apple-converted-space">=A0 =
</SPAN><A =
href=3D"http://www.iptc.org/IPTC7901/">http://www.iptc.org/IPTC7901/</A></=
DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">The IPTC has decided to develop new family of news =
exchange standards -</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">the G2-Standards - for =
conveying different types of content. They will</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">be successors to the current versions of NewsML 1.x, =
SportsML 1.x.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Further to that a standard for =
exchanging event information - EventsML -</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">is also =
be developed at this stage.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">After an "Experimental Phase 1" =
(EP#1) in winter 2005/2006, another EP#2</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">in =
summer 2006 and a final Release Candidate (RC) review in early =
2007</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">the structures of the News =
Architecture 1.0 were approved by the IPTC on</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">30 May 2007. This includes the data model and all =
properties but</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">excludes the Processing =
Model.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">You may download the NAR 1.0 package, a ZIP file =
(</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; "><A =
href=3D"http://www.iptc.org/std/NAR/NAR_1.0.zip">http://www.iptc.org/std/N=
AR/NAR_1.0.zip</A> ) containing these individual</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">documents and also find more information about the =
G2 family of news</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">exchange standards on the IPTC =
website at: <A =
href=3D"http://www.iptc.org/NAR/">http://www.iptc.org/NAR/</A><SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">What we are =
looking to do is to formally register media types based on</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">XML for this new family of news exchange standards =
in the vendor tree.<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Specifically, with this request, we are seeking to register =
the</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">following media type:</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 =
</SPAN>application/vnd.iptc.g2.knowledgeitem+xml<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">A version of =
the form we wish to submit follows. If this submission</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">requires additional information for community review =
and IANA approval,</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">please let us =
know.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">---------- the form ----------</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Media Type Name: =
application<SPAN class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Subtype =
name: vnd.iptc.g2.knowledgeitem+xml</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Required parameters: =
none</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Optional parameters: Identical to those of =
"application/xml" as</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">described in rfc3023, =
section 3.2</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Encoding =
considerations: Identical to those of "application/xml" as</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">described in rfc3023, section 3.2</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Security =
considerations: Identical to those of "application/xml" as</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">described in rfc3023, section 10</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Interoperability considerations: Identical to those of =
"application/xml"</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">as described in rfc3023, section =
3.1</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Published specification:<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 =A0 =
</SPAN>NAR_1.0-spec-ModelCore_16.pdf<SPAN =
class=3D"Apple-converted-space">=A0 =A0 =A0</SPAN></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"http://www.iptc.org/std/NAR/1.0/specification/NAR_1.0-spec-ModelCo=
re_16.pdf">http://www.iptc.org/std/NAR/1.0/specification/NAR_1.0-spec-Mode=
lCore_16.pdf</A></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-converted-space">=A0 =A0 =
</SPAN>NAR_1.0-spec-ModelPowerExt_16.pdf<SPAN =
class=3D"Apple-converted-space">=A0 =A0</SPAN></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"http://www.iptc.org/std/NAR/1.0/specification/NAR_1.0-spec-ModelPo=
werExt_16.pdf">http://www.iptc.org/std/NAR/1.0/specification/NAR_1.0-spec-=
ModelPowerExt_16.pdf</A></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Applications which use this media type: none<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Additional =
information:<SPAN class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Magic =
number(s):<SPAN class=3D"Apple-converted-space">=A0 =A0 =A0 =A0 =A0 =A0 =
=A0 </SPAN>none</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">File extension(s):<SPAN =
class=3D"Apple-converted-space">=A0 =A0 =A0 =A0 =A0 =A0 =
</SPAN>xml</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Macintosh File Type Code(s): =
<SPAN class=3D"Apple-converted-space">=A0 </SPAN>Identical to those of =
"application/xml"</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">as described in rfc3023, =
"TEXT"</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Object =
Identifier(s) or OID(s):<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">It must be =
possible to positively identify an Item as it moves through</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">the news workflow, and is transferred from place to =
place and from</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">system to system. An Item =
therefore gets a globally unique identifier</DIV><DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">(guid), =
which is a persistent, universally unique identifier, and a</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">version which is incremented when the content of the =
Item is updated.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">The first version is numbered 1: =
if the version is not explicitly set,</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">this =
value must be assumed by the recipient of the Item. The guid =
is</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; ">required to be in the form of a IRI. Any IRI =
capable of acting as a</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">globally unique identifier =
is accepted; the IPTC provides a standard for</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">this purpose in the form of an IETF RFC [RFC-3085]. =
@@ At the time of</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">this writing the RFC 3085, =
initially defined in the scope of NewsML1, is</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">still to be complemented by a new RFC in which =
globally unique</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">identifier and version are =
separate properties.<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Intended usage:</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Knowledge Item is a set of concept definitions or classes extended =
with</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">specific properties, e.g. with =
specific information about a person</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">grouped =
together to form a consistent structure, which is managed,</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">protected and published as a whole.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>A Knowledge Item should be =
used to</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">convey snapshots of the set of =
concepts adopted by a controlled</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">vocabulary =
e.g. where a provider wants to circulate a set of entries</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">from one or more controlled vocabularies, =
representing something like a</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">thesaurus, a =
taxonomy or an authority list. <SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Other =
Information/General Comment: none</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Person to contact for further information:<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>Name: Michael =
Steidl</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>E-mail: <A =
href=3D"mailto:[email-masked]">[email-masked]</A></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Author/Change =
controller:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>Name: Michael Steidl</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>E-mail: <A =
href=3D"mailto:[email-masked]">[email-masked]</A></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV> =
</BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-19--6196072--

Date: Fri, 03 Aug 2007 17:22:51 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Issue 63: Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART

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: "Tim Hare" <[email-masked]>
To: "'Lorenzo De Tomasi'" <[email-masked]>, <[email-masked]>
Subject: RE: [Ietf-calsify] Proposal of "Collections of events"
Date: Thu, 2 Aug 2007 08:48:20 -0400

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Lorenzo De
Tomasi
Sent: Thursday, August 02, 2007 7:00 AM
To: [email-masked]
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
<exhibition>
 <conference>
  <talk />
  <talk />
  .
 </conference>
 <presentation>
  <movie />
  <talk />
  .
 </presentation>
</exhibition>

or

<championship>
  <inauguration />
  <match />
  <match />
  .
 <winner_proclamation />
</championship>

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

<event id="match1">
 .
 <a rel="child_of" href="#championship" /> </event> <event
id="championship">  .  <a href="parent_of" href="#match1" /> </event>

Also a single relationship (->) can be permitted,

<event id="match1">
 .
</event>
<event id="championship">
 .
 <a href="parent_of" href="#match1" />
</event>

or

<event id="match1">
 .
 <a rel="child_of" href="#championship" /> </event> <event
id="championship">  . </event>

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
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Thu, 2 Aug 2007 12:59:51 +0200
From: "Lorenzo De Tomasi" <[email-masked]>
To: [email-masked]
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
<exhibition>
 <conference>
  <talk />
  <talk />
  =85
 </conference>
 <presentation>
  <movie />
  <talk />
  =85
 </presentation>
</exhibition>

or

<championship>
  <inauguration />
  <match />
  <match />
  =85
 <winner_proclamation />
</championship>

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

<event id=3D"match1">
 =85
 <a rel=3D"child_of" href=3D"#championship" />
</event>
<event id=3D"championship">
 =85
 <a href=3D"parent_of" href=3D"#match1" />
</event>

Also a single relationship (->) can be permitted,

<event id=3D"match1">
 =85
</event>
<event id=3D"championship">
 =85
 <a href=3D"parent_of" href=3D"#match1" />
</event>

or

<event id=3D"match1">
 =85
 <a rel=3D"child_of" href=3D"#championship" />
</event>
<event id=3D"championship">
 =85
</event>

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.
--=20
Lorenzo De Tomasi
Designer multimodale
http://www.ipernico.it
http://www.isotype.org (in costruzione)

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: f75ea54047bda38c66095cebf3942f28
X-Spam-Score-Summary: 50, 0, 0, 7384d388059fef5b, 125bcd2cf611e98c, [email-masked], , RULES_HIT:4:69:152:355:379:539:540:541:542:543:567:945:946:966:973:982:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1587:1593:1594:1605:1676:1730:1747:1766:1792:2073:2075:2078:2110:2196:2198:2199:2200:2379:2393:2551:2553:2559:2560:2561:2562:2640:2693:2892:2893:2900:3027:3636:3740:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4250:4385:4425:4605:5007:6117:6119:6261, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Subject: "Re: [Ietf-calsify] Working Group Last Call:draft-ietf-calsify-rfc2445bis-07.txt
Date: Wed, 1 Aug 2007 16:46:04 +0100

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