Subject: [APPS-REVIEW] [xml-dev] Re: Metalink XML Download Description Format (draft-bryan-metalink-01)
From: "Anthony Bryan" <[email-masked]>
To: "general discussion of application-layer protocols" <[email-masked]>, "Applications Review List" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Sat, 20 Sep 2008 19:26:22 -0400
List-Id: Applications Review List <apps-review.ietf.org>

Greetings,

An updated Internet Draft for Metalink is available at
http://tools.ietf.org/html/draft-bryan-metalink-03
with interim revisions at
http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ .

We're looking for review and public comments.

  Metalink is an XML-based document format that describes a file or
  lists of files to be added to a download queue.  Lists are composed
  of a number of files, each with an extensible set of attached
  metadata.  For example, each file can have a description, checksum,
  and list of URIs that it is available from.

  The primary use case that Metalink addresses is the description of
  downloadable content in a format so download agents can act
  intelligently and recover from common errors with little or no user
  interaction necessary.  These errors can include multiple servers
  going down and data corrupted in transmission.

This updated version incorporates comments:

- urn:ietf:params:xml:ns:metalink namespace & registration.
- IANA "Operating System Names" registry for listing the OS that a
file listed in a metalink is for. This registry would need to be
updated to be useful.
- new "Client Implementation Considerations" . Currently, this section
mentions transparent content negotiation.

Issues:
- Inclusion of digital signatures other than PGP of files listed in
the Metalink. (Only PGP is currently supported). What do we need to
add and how might we need to restructure this for other digital
signatures to be included/used?
- Proxies. If a file listed in a metalink is already in a cache, but a
different URI is used then I assume it won't be recognized and will be
requested again since it seems to be an uncached file. I'm wondering
if the checksums in a metalink or something else could be used to see
if the file is the same or not.

Thank you,

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
 )) Easier, More Reliable, Self Healing Downloads

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: [email-masked]
subscribe: [email-masked]
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-review

Date: Sat, 20 Sep 2008 19:26:22 -0400
From: "Anthony Bryan" <[email-masked]>
To: "general discussion of application-layer protocols" <[email-masked]>,  "Applications Review List" <[email-masked]>,  [email-masked], [email-masked]
Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01)
Sender: [email-masked]

Greetings,

An updated Internet Draft for Metalink is available at
http://tools.ietf.org/html/draft-bryan-metalink-03
with interim revisions at
http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ .

We're looking for review and public comments.

  Metalink is an XML-based document format that describes a file or
  lists of files to be added to a download queue.  Lists are composed
  of a number of files, each with an extensible set of attached
  metadata.  For example, each file can have a description, checksum,
  and list of URIs that it is available from.

  The primary use case that Metalink addresses is the description of
  downloadable content in a format so download agents can act
  intelligently and recover from common errors with little or no user
  interaction necessary.  These errors can include multiple servers
  going down and data corrupted in transmission.

This updated version incorporates comments:

- urn:ietf:params:xml:ns:metalink namespace & registration.
- IANA "Operating System Names" registry for listing the OS that a
file listed in a metalink is for. This registry would need to be
updated to be useful.
- new "Client Implementation Considerations" . Currently, this section
mentions transparent content negotiation.

Issues:
- Inclusion of digital signatures other than PGP of files listed in
the Metalink. (Only PGP is currently supported). What do we need to
add and how might we need to restructure this for other digital
signatures to be included/used?
- Proxies. If a file listed in a metalink is already in a cache, but a
different URI is used then I assume it won't be recognized and will be
requested again since it seems to be an uncached file. I'm wondering
if the checksums in a metalink or something else could be used to see
if the file is the same or not.

Thank you,

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
 )) Easier, More Reliable, Self Healing Downloads
_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-review

Date: Mon, 15 Sep 2008 12:46:07 -0700
To: Lisa Dusseault <[email-masked]>, [email-masked], [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: [APPS-REVIEW] HTML5 for email client implementors
Sender: [email-masked]

At 10:38 AM -0700 9/15/08, Lisa Dusseault wrote:
>I've been looking at HTML5 (http://www.w3.org/html/wg/html5/) and its 
>gigantic spec, and discussing a bit with the W3C and IETF liaisons.  
>It's a drastic new approach to HTML.  One of the aspects I'd like to 
>see get IETF input, is the expansion in scope of requirements.
>
>Can an email client be compliant with HTML5 -- is that a reasonable 
>expectation?  What about other software applications that use HTML but 
>are not browsers?
>
>If you can take a look and answer this question, the HTML5 WG does of 
>course encourage direct input to its mailing list (specified in doc 
>linked above).  A volunteer aka victim for that would be best, if not 
>several.  But if you can reply off-the-cuff to me or this group, that
>alone would be a good thing.

A bit of history. The Internet Mail Consortium talked about HTML 
compliance about eight years ago and walked away from it. There was a 
strong user expectation that an HTML-encoded message would appear in 
the MUA the same as it would appear if opened in their favorite 
browser. At the time, there was not nearly as much renderer-sharing 
across applications as there is now. Because of that, some MUA 
vendors (including Microsoft) didn't show things the same as 
IE/Netscape did. The world renders differently now.
_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-review

From: Lisa Dusseault <[email-masked]>
To: [email-masked], [email-masked]
Date: Mon, 15 Sep 2008 10:38:00 -0700
Subject: [APPS-REVIEW] HTML5 for email client implementors
Sender: [email-masked]

I've been looking at HTML5 (http://www.w3.org/html/wg/html5/) and its  
gigantic spec, and discussing a bit with the W3C and IETF liaisons.   
It's a drastic new approach to HTML.  One of the aspects I'd like to  
see get IETF input, is the expansion in scope of requirements.

Can an email client be compliant with HTML5 -- is that a reasonable  
expectation?  What about other software applications that use HTML but  
are not browsers?

If you can take a look and answer this question, the HTML5 WG does of  
course encourage direct input to its mailing list (specified in doc  
linked above).  A volunteer aka victim for that would be best, if not  
several.  But if you can reply off-the-cuff to me or this group, that  
alone would be a good thing.

thx,
Lisa
_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-review

Date: Sun, 07 Sep 2008 22:57:22 -0400
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, Eric Burger <[email-masked]>, ietf-calsify list <[email-masked]>, [email-masked],  Lisa Dusseault <[email-masked]>
Subject: Re: [APPS-REVIEW] IETF Review of rfc2446bis-07
Sender: [email-masked]

Hi Reinhold,

--On September 8, 2008 3:14:35 AM +0200 Reinhold Kainhofer 
<[email-masked]> wrote:

> Attached is my review, where I mention all issues / questions
> sequentially,  ordered as they appear in the draft (thus mixing errors
> with open questions  and suggestings).

Thank you for this extremely thorough review of this specification.

There are 123 points made about 2446bis. What I will need to do is import 
these into a spreadsheet so that I can track responses and changes to 
these. Anything that requires more than a simple fix will probably need to 
be raised as an issue on the issue tracker, assuming the chairs are 
willingly to re-open that to address this review.

> PS: Sorry (well, not really...) for all the work that my review will
> bring to  the ietf calsify team, but well, you asked for it ;-)

Well you did such a good job that it might backfire on you as I am sure 
Eric and the Apps Review team will be targeting you to do lots more :-)

-- 
Cyrus Daboo

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-review

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: Eric Burger <[email-masked]>, "ietf-calsify list" <[email-masked]>, [email-masked], Lisa Dusseault <[email-masked]>
Date: Mon, 8 Sep 2008 03:14:35 +0200
Subject: [APPS-REVIEW] IETF Review of rfc2446bis-07
Sender: [email-masked]

--Boundary-00=_7xHxICeqGLWTPkk
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Dear Calsify group, dear apps-review team,

Eric Burger asked me if I could review the latest draft of rfc2446bis, which I 
agreed to. I tried to read the draft very carefully and with utmost 
diligence, trying to be extremely picky. I found lots of issues, obvious 
typos and contradictions, or simply things that should/might be explained a 
little better. There are also some things that I've not completely understood 
from the draft. 

Attached is my review, where I mention all issues / questions sequentially, 
ordered as they appear in the draft (thus mixing errors with open questions 
and suggestings).
I wrote it in LaTeX, mainly because of its size and to make cross-references 
and automatic numbering easier. I'm attaching the PDF file, the LaTeX source 
document and a HTML-representation produced by hyperlatex (with some tweaks 
to achieve the consecutive item numbering for the lists).

I know that some of the things might sound like nitpicking. However, from my 
experience with RFC 2445, if there is anything that can possibly be 
misunderstood, it will probably be misunderstood by some implementor.
Thus, I strived to find also all the spots where things could be spelled out a 
little more detailled. In my eyes, a standards document should be unambiguous 
and still easy to understand. Please view my comments in this light.

On the other hand, I really wonder how things like the following could have 
survived in a public RFC for more than a decade:
   DTSTART:19980101T100000-0700
or
   STATUS:IN-PROGRESS
for a todo or
   RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU
for an event that should recur every week for 20 weeks or
   DTSTART:19970701T200000Z
   DTEND:19970701T2000000Z
for an event or completely messed-up timezone conversions (Sec. 4.4.1).

Most of my points do not change the meaning of the RFC draft at all and can 
probably be included with only very little discussion / controversy.

While cross-checking some issues, I also came across some things in 
rfc2445bis-08, which might be changed there. These are listed at the end of 
my review.

Cheers,
Reinhold

PS: Sorry (well, not really...) for all the work that my review will bring to 
the ietf calsify team, but well, you asked for it ;-)

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

--Boundary-00=_7xHxICeqGLWTPkk
Content-Type: application/pdf;
  name="Review_RFC2446bis_2008-09.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="Review_RFC2446bis_2008-09.pdf"

--Boundary-00=_7xHxICeqGLWTPkk
Content-Type: text/html;
  charset="iso 8859-15";
  name="Review_RFC2446bis_2008-09.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Review_RFC2446bis_2008-09.html"

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!-- XML file produced from file: Review_RFC2446bis_2008-09.tex
     using Hyperlatex v 2.9-in-waiting-rk (oct06) (c) Otfried Cheong
     on Emacs 22.1.1, Mon Sep  8 02:54:18 2008 -->
<head>
<title>IETF Review of the RFC 2446bis-07 (iTIP) draft</title>

<style type="text/css">
.maketitle { align : center }
div.abstract { margin-left: 20%; margin-right: 10%; }
h3.abstract  { align : center }
div.verse, div.quote, div.quotation {
  margin-left : 10%; 
  margin-right : 10%;
}
dt {font-weight: bold}
</style>
</head>
<body>
<p><h1 class="maketitle"><b>IETF Review of the RFC 2446bis-07 draft:<br />iCalendar Transport-Independent Interoperability Protocol (iTIP)</b></h1>
<h2 class="maketitle">Reviewer: <a href="mailto:[email-masked]">Reinhold Kainhofer</a></h2>
<h3 class="maketitle">September 7, 2008</h3>
</p>

<h1><a name="id1">About this review</a></h1>
<p>Since this draft is an update to an already existing standard, I will
not comment on its usefulness in general, but rather concentrate on technical
details. In particular, I looked at possible contradictions to
rfc2445bis-08, unclear explanations,
formulations that might possibly be misunderstood, and typos. The
page-breaking of the draft is also not ideal, but I suppose this
will be fixed in the final release, so I will not further comment on it.
Even though several of the issues I found were already detailled in
Lisa Dusseault's review, I will still list them here.
</p>
<p>I will go through the whole draft section by section, mixing comments of
different types, like errors, unclear formulations, other suggestions
and questions I still have, etc.
I will use one item per issue I found, even when I found multiple
issues in a section. This will make it easier to discuss the issues.
</p>
<p>Quotes from the draft and rfc2445bis as well as text to be 
inserted into the draft will be placed in &raquo;guillemets&laquo; to 
destinguish them from text in quotations marks in the draft (like 
all property and method names).
</p>

<h1><a name="id2">General observations</a></h1>
<ol start=1> <li>
<p>The capitalization of &raquo;event&laquo; is inconsistent throughout
the draft. Sometimes, &raquo;Event&laquo; is used inside a sentence, at other
times &raquo;event&laquo; is used.
</p>
</ol>

<h1><a name="id3">Introduction and overview</a></h1>
<ol start=2> <li>
<p>Abstract (p.1): &raquo;calendar systems&laquo; should be replaced by &raquo;calendaring systems&laquo; to prevent any possible confusion. iTIP is only about the Gregorian calendar system.
</p>
<p><li>Sec.&nbsp;1.3 (p.6): This draft also describes forwarding, where
there is a third role involved, namely "Other CUs". Also, when
delegating, the delegate is not an &raquo;"Attendee" asked to participate
by the "Organizer"&laquo;, so it does not strictly fulfill the definition
of the Attendee role of section 1.3., either.
</p>
<p><li>Sec.&nbsp;1.3 (p.7): The definition of the Attendee uses &raquo;participate&laquo;, which does not make sense for to-dos.
</p>
<p><li>Sec.&nbsp;1.4 (p.7): In the REQUEST Description: Change &raquo;Meeting Requests&laquo; to &raquo;Meeting requests&laquo;
</p>
<p><li>Sec.&nbsp;1.4 (p.8): Why are Attendees not allowed to PUBLISH a group event?
</p>
</ol>

<h1><a name="id4">Interoperability Models</a></h1>
<ol start=7> <li>
<p>Sec.&nbsp;2.1.1 (p.9): &raquo;When an "Organizer" issues the initial
entry, "Attendee" status is unknown.&laquo; The Organizer might have had other
communication with the Attendee and already know the status
from other means than iTIP. I would insert the word &raquo;typically&laquo;
before &raquo;unknown&laquo;.
</p>
<p><li>Sec.&nbsp;2.1.4 (p.10f): This section heavily refers to the rules
for incrementing the "SEQUENCE" number in I&#95;D.ietf-calsify-rfc2445bis].
However, rfc2445bis-08 only says: &raquo;It is monotonically
incremented by the "Organizer's" CUA each time the "Organizer"
makes a significant revision to the calendar component.&laquo;
The rest of the rules was removed from rfc2445bis in rfc2445bis-08,
but has not been added to rfc2446bis. I propose to remove all
references to rfc2445bis in this section and instead paste the
rules into rfc2446bis:
</p>
<pre>
   The "SEQUENCE" property is used by the "Organizer" to indicate
   revisions to the calendar component. When the "Organizer" makes
   changes to one of the following properties, the sequence number
   MUST be incremented:
      *  "DTSTART"
      *  "DTEND"
      *  "DURATION"
      *  "DUE"
      *  "RDATE"
      *  "RRULE"
      *  "EXDATE"
      *  "STATUS"

   In addition, changes made by the "Organizer" to other properties
   MAY also require the sequence number to be incremented.  The
   "Organizer" CUA MUST increment the sequence number whenever it
   makes changes to properties in the calendar component that the
   "Organizer" deems will jeopardize the validity of the
   participation status of the "Attendees".  For example, changing
   the location of a meeting from one location to another distant
   location could effectively impact the participation status of the
   "Attendees".

   Depending on the METHOD, the "SEQUENCE" property MUST follow
   these rules in the context of iTIP:
     * For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE"
       property value is incremented according to the rules stated
       above.
     * The "SEQUENCE" property value MUST be incremented each time the
...  [rest is taken as found in rfc2446bis-07] ...
  </pre>
<p><li><a name="SEQUENCE_MultipleUID">Sec.&nbsp;2.1.5</a> (p.11/12): From this description, it appears
to me that all calendar components with the same UID also need
to have the SEQUENCE incremented simultaneously (i.e. if the Organizer changes just one
occurrence from a recurring sequence, he must increase the
SEQUENCE not only of that particular VEVENT, but also of the
VEVENT containing the RRULE). This was not clear to me from
rfc2445bis and is never clearly spelled out. In particular,
rfc2445bis says on page 142 that &raquo;SEQUENCE defines the revision
sequence number of the calendar component within a sequence of
revisions&laquo; and defines calendar component on pages 52ff as
any VEVENT, VTODO, VJOURNAL, etc. inside the VCALENDAR.
In particular, a VEVENT with
an RRULE and another VEVENT with the same UID, but using
RECURRENCE-ID to modify one single instance of the recurrence,
are actually two calendar components, as far as I understand
the wording. The description of SEQUENCE can then be understood
that both can have different SEQUENCE numbers...
</p>
<p>This should probably be clarified in rfc2445bis.
</p>
<p>If, however, it is possible for the two components to have
different SEQUENCE numbers, then items 3. and 4. of the list in
section 2.1.5 need to be changed from &raquo;UID&laquo; to &raquo;UID and
RECURRENCE-ID&laquo;.
</p>
<p><li>Sec.&nbsp;2.1.5 (p.12): &raquo;Hence, CUAs must persist&laquo; should rather
be &raquo;Hence, CUAs MUST persist&laquo;
</p>
<p><li>Sec.&nbsp;2.1.5 (p.12): I don't understand what is meant with the
sentence &raquo;Furthermore, for each "ATTENDEE" property of a component
CUAs must persist the "SEQUENCE" and "DTSTAMP" property values
associated with the "Attendee's" response.&laquo; First, I don't understand
the meaning: Does this mean that the Organizer's CUA needs to store
for each Attendee the last SEQUENCE number, to which the Attendee has
responded? In this case, I don't understand the reason behind it.
Or does it mean that the Attendee's CUA needs to preserve the
SEQUENCE of his/her last response, so that it's possible to decide
whether a response to a new REQUEST from the Organizer is needed.
In that case, I don't think that sentence is needed, either,
because it is stated in the draft already that only the Organizer
is allowed to make changes to a component.
Also, which CUAs are meant: The CUA of the Organizer or of the Attendee?
</p>
</ol>

<h1><a name="id6">Application Protocol Elements</a></h1>
<ol start=12> <li>
<p>Sec.&nbsp;3 (p.12, methods table): From the VJOURNAL column,
it seems to me that CANCEL and ADD can also be used change
components that were PUBLISHed, not only REQUESTed ones.
This is never clearly spelled out, in particular not for VEVENT
and VTODO.
</p>
<p><li>All the restriction tables in this chapter list the
VALARM component parallel to VEVENT, VTODO, VJOURNAL and VFREEBUSY.
I regard this as quite unfortunate, because VALARM is not a top-level
calendar component, but can only appear inside other components.
As the description of the tables says that component properties
are indented, I think it would make sense to also indent VALARM,
which is a component component.
</p>
<p><li><a name="DTSTART_Absent">Several</a> of the constraint tables for VEVENT in chapter 3
either disallow DTSTART at all or allow DTSTART to be absent
from a component. In particular, the VEVENT REFRESH (Sec.&nbsp;3.2.6, p.28)
and DECLINECOUNTER (Sec.&nbsp;3.2.8, p.31) tables disallow DTSTART at
all, while VEVENT CANCEL (Sec.&nbsp;3.2.5, p.27), allow &raquo;0 or 1&laquo; DTSTART.
In contrast, rfc2445bis (Sec.&nbsp;3.6.1, p.54) REQUIRES DTSTART to
be present in all VEVENT components, so that e.g. the contents
of a REFRESH are NOT VALID iCalendar! Notice, that this restriction
in rfc2445bis was not in rfc2445, but was added during the update 
to rfc2445bis.
</p>
</ol>

<h2><a name="id8">Common Component Restriction Tables</a></h2>
<ol start=15> <li>
<p>Sec.&nbsp;3.1.2 (p.14, VTIMEZONE table): This table states that
RRULE and RDATE MUST NOT both be present at the same time.
rfc2445bis does not have such a restriction, so that some
VTIMEZONE objects, which are valid in rfc2445bis, cannot be
used for group scheduling. I propose to remove that restriction.
</p>
</ol>

<h2><a name="id9">Methods for VEVENT Calendar Components</a></h2>
<ol start=16> <li>
<p>Sec.&nbsp;3.2 (p.15, methods table, REQUEST): &raquo;Event requests&laquo;
instead of &raquo;Event Requests&laquo;. Also, I think it should be
&raquo;MAY degrade&laquo; instead of &raquo;may degrade&laquo;.
</p>
<p><li>Sec.&nbsp;3.2.1 (p.16): I have never understood why a PUBLISHed
event MUST NOT have any Attendees. In particular, I think it
might be useful for several types of published events to contain
Attendees and their participation status: panel discussions,
hearings, etc.
</p>
<p><li><a name="REQUEST_privacy_all_attendees">Sec.&nbsp;3.2.2</a> (p.16ff):
Is there any requirement that the VEVENT REQUEST
sent out to one particular Attendee MUST/SHOULD contain
all other Attendees? Cf. in particular Sec.&nbsp;3.2.5 (see issue
<a href="#CANCEL_privacy_all_attendees">*</a>), which states
that a cancelled event MUST include all Attendees. In my opinion,
there should not be such a requirement, mainly for privacy reasons.
The attendees' email addresses are explicitly listed in the
ATTENDEE property, so I don't regard it a good idea that all
attendees automatically learn about the email addresses of all
other attendees, which might be well-known persons and quite
reluctant to give out their private contact details.
In any case, a sentence should be inserted clarifying whether
all attendees MUST/SHOULD be given in the VEVENT, or whether it
is possible to send individual requests to each attendee containing
only the one ATTENDEE property for this particular person.
</p>
<p><li>Sec.&nbsp;3.2.2 (p.17): The paragraph after the list is not
true for delegated and forwarded events.
In particular, in both cases the recipients are not the
"Attendees", but "Other CUs".
</p>
<p><li>Sec.&nbsp;3.2.2.3 (p.21): In the second-to-last paragraph,
there is a spurious " between method and SHOULD.
</p>
<p><li>Sec.&nbsp;3.2.2.3 (p.20/21): The delegator forwards the REQUEST
to the delegate, including the delegate as a new ATTENDEE. The
delegator also sends a REPLY to the Organizer with the DELEGATED-TO
parameter set. However, it is not clear to me whether the REPLY to
the organizer MUST/SHOULD also contain the delegate as a new ATTENDEE
or not. As the comment in Sec.&nbsp;4.2.5 says this is a MUST, 
it should be added here, too, since here is the section where 
delegating is actually defined. The examples - helpful as they 
are - should not include any new requirements not described 
before.
</p>
<p><li>Sec.&nbsp;3.2.2.4 (p.21): In the last sentence, it should read
&raquo;... incremented and the value of ...&laquo;.
</p>
<p><li>Sec.&nbsp;3.2.2.4 (p.21): The last sentence says that &raquo;the
"ORGANIZER" property has been changed to the <em>calendar address</em>
of the new "Organizer".&laquo; However, rfc2445bis defines the calendar
address as only the URI and does not include property
parameters like CN, which should clearly be changed, too.
I think it would suffice to simply say &raquo;and the value of the
"ORGANIZER" property has been changed to the new "Organizer".&laquo;
</p>
<p><li>Sec.&nbsp;3.2.2.6 (p.21): There is one step missing in the
description: The Attendee forwards to the uninvited CU, but there
is no mentioning of how the Organizer learns of this.
</p>
<p><li><a name="TODO_Forwarding_OrganizerResponse"> Sec.&nbsp;3.2.2.6</a> (p.21): How does the uninvited CU find out whether
the Organizer added him/her or not. The draft only says that the
Organizer MAY send a CANCEL if he rejects the new Attendee. However,
if he does not, then the uninvited Attendee has no way of knowing
whether he was added or not. A sentence should be added clarifying
this situation. Should the uninvited CU simply send a REFRESH to
the organizer? If he does not get a response there either, he can
deduce that he was not added (see Sec.&nbsp;6.1.6).
</p>
<p><li>Sec.&nbsp;3.2.2.6 (p.22): The last sentence says that the Attendee
MUST NOT make changes to the VEVENT property set. However, this would
not prohibit changes to other calendar components, like VTIMEZONE,
VALARM, etc. I don't think such changes should be allowed, either.
</p>
<p><li>Sec.&nbsp;3.2.3 (p.22): Should &raquo;An "Attendee" can include&laquo; rather
be &raquo;An "Attendee" MAY include&laquo;?
</p>
<p><li><a name="VEVENT_NotChanged"> Sec.&nbsp;3.2.3</a> (p.23): This section says that the optional
properties listed in the table MUST NOT be changed. However,
the rest of the draft and the comments in the table make it clear
that some required parameters (DTSTAMP, UID, ORGANIZER) MUST also
NOT be changed.
</p>
<p><li>Sec.&nbsp;3.2.3 (p.24): The table lists VALARM as &raquo;0&laquo;. If the
original REQUEST contained a VALARM, shouldn't it be included in
the REPLY, too?
</p>
<p><li><a name="ADD_Explanation"> Sec.&nbsp;3.2.5</a> (p.24f): 
I don't understand
how ADD should work exactly. rfc2445bis says that an instance of
an event is identified by the UID and the RECURRENCE-ID. If we
don't allow a RECURRENCE-ID, how does the resulting sequence
of events look in iCalendar notation (i.e. what would the
Organizer send in response to a REFRESH)?
</p>
<p>I suppose it would work to add the additional date as an RDATE
or a second RRULE, but only if none of the other properties
is different from the original event. Sec.&nbsp;4.4.7 gives an
example of this case (but since it does not point out that an
RDATE was added, it is very hard to figure out how the
ADD was handled). If some properties are different for a single
ADDed event, this can still be represented as an added RDATE
and a second VEVENT using RECURRENCE-ID to specify the added
instance. However, if an ADD message tries to add a recurring
event with some property values different from the original
(already recurring) event, then I simply don't see how this can
be represented in iCalendar.
RECURRENCE-ID;RANGE=THISANDFUTURE can not be used, because the
change should only apply to the instances of one RRULE, not of both.
</p>
<p>An example of this problem is the first example in Sec.&nbsp;4.4.7:
The original RRULE recurs on TU in &raquo;The White Room&laquo;. The ADD
message adds a second rule on TH, but the location is now &raquo;The
usual conference room&laquo; (see also issue <a href="#ADD_Recurrence">*</a>). I don't see how these two combined can
be properly represented in the same event in iCalendar.
The example says that they are equivalent to the REQUEST given in
Sec.&nbsp;4.4.7, but that REQUEST seems to ignore the different
LOCATION property value of the ADD. I think it should be clarified, how such
colliding messages should be handled. In particular, do all other
property values except DTSTART, RDATE and RRULE have to coincide
with the original REQUEST?
If not, we should clarify how that case can be handled (i.e. either
discard all information from the ADD, which does not coincide? Or
try to merge them as much as possible? Or simply disallow adding
recurring events to an already recurring event with different
properties.)
</p>
<p>The same clarification is needed for VTODO (p.47)
</p>
<p><li>Sec.&nbsp;3.2.5 (p.26): The first sentence talks about sending a
notice &raquo;to the "Attendees"&laquo;. To me it is not clear if this means
sending a CANCEL message to ALL Attendees (even when just
uninviting one Attendee) or only to the affected (i.e. uninvited)
Attendees. Both would make sense...
</p>
<p>The same goes for VTODO on p.47.
</p>
<p><li>Sec.&nbsp;3.2.5 (p.26): In the ATTENDEE comment in the table,
&raquo;from&laquo; is missing in &raquo;being removed from the event.&laquo;
</p>
<p><li><a name="CANCEL_privacy_all_attendees">Sec.&nbsp;3.2.5</a> (p.26): Why is it a MUST that all Attendees have
to be included if the whole event is cancelled? The STATUS property
already tells the CU(A) whether the whole event was cancelled or
only some Attendees uninvited. Can't a CUA also send out individual
CANCEL messages to each of the Attendees with only that one Attendee
included in the VEVENT? This would prevent privacy issues, because
sending out the email addresses of all Attendees is not always
desirable (see also issue <a href="#REQUEST_privacy_all_attendees">*</a>).
</p>
<p>The same holds for VTODO (p.49)
</p>
<p><li>Sec.&nbsp;3.2.5 (p.27): The description of STATUS in the table
is badly worded (Isn't this a contradiction: MUST be set to CANCELLED,
and MUST NOT be present, if ....).
I propose to change the first part of the description to
</p>
<pre>
     MUST be set to CANCELLED to cancel the entire event.
  </pre>
<p><li>Sec.&nbsp;3.2.6 (p.28): I think DTSTAMP and ORGANIZER also MUST
be the same value as in the original REQUEST...
</p>
<p><li><a name="REC-ID_VTIMEZONE_required">Sec.&nbsp;3.2.6</a> (p.29): Since RECURRENCE-ID is a date-time value,
it might include a reference to a time zone. In this case, a VTIMEZONE is REQUIRED (instead of the current &raquo;0&laquo;)
</p>
<p><li>Sec.&nbsp;3.2.7 (p.29, first paragraph): The COUNTER is used not only
for counter proposals to the event description! I would simply delete
&raquo;description&laquo; so the sentence reads &raquo;... a counter proposal to
the event.&laquo;
</p>
<p><li>Sec.&nbsp;3.2.7 (p.30): The SEQUENCE value MUST NOT be changed
from the original event. I would include this in the comment for
SEQUENCE (it is mentioned in the examples in Sec.&nbsp;4.2.4, though).
</p>
<p><li>Sec.&nbsp;3.2.7 (p.30): In the comment for STATUS, remove the
space before CANCELLED.
</p>
<p><li>Sec.&nbsp;3.2.7 (p.31): At the end of this section, it should
be clarified how the Organizer reacts to the COUNTER. Declining
it is clear, but if he accepts it, does he have to send out a
new REQUEST to all Attendees or can he simply do nothing, too?
In particular, if an Attendee sends a COUNTER with significant
changes and does not receive a DECLINECOUNTER, can he assume that
the Organizer has accepted it or does he have to treat it like 
receiving a DECLINECOUNTER? How does he learn about it other
than sending a REFRESH?
</p>
<p><li>Sec.&nbsp;3.2.8 (p.32): VTIMEZONE is required if the RECURRENCE-ID
contains a reference to a timezone! (like issue <a href="#REC-ID_VTIMEZONE_required">*</a>).
</p>
</ol>

<h2><a name="id16">Methods for VFREEBUSY Components</a></h2>
<ol start=42> <li>
<p>Sec.&nbsp;3.3 (p.32): The third paragraph says that the
VFREEBUSY MUST include the ATTENDEE in this case, while the
PUBLISH table in Sec.&nbsp;3.3.1 expressively forbid this.
</p>
<p><li>Sec.&nbsp;3.3 (p.33): This section says &raquo;However, two
different busy time periods MAY overlap&laquo;, while the restriction
table in REPLY (sec 3.33, p.36) says that they MUST NOT overlap.
</p>
<p><li>Sec.&nbsp;3.3 (p.33): Shouldn't it be a SHOULD in &raquo;"FREEBUSY"
properties should be sorted...&laquo;?
</p>
<p><li>Sec.&nbsp;3.3 (p.33): The paragraph starting with &raquo;Since
events may span a day boundary...&laquo; is confusing at best. The
free/busy periods do not necessarily coincide with events, so
this is no argument. Also, the following sentence sounds a bit
out of order, since it clarifies the REQUEST method. Instead of
giving such a lengthy example (talking about "Individuals" not
supporting busy time requests, while in fact their CUAs don't
support it), wouldn't it be simpler to reformulate the whole
paragraph?
</p>
<p>I propose to append
</p>
<pre>    Busy time periods may also span a day boundary.</pre>
<p>to the previous paragraph and remove the rest of the paragraph,
since it deals with a fallback and only explains what the methods fallback table in
Sec.&nbsp;5.1.2 already says much better.
</p>
<p><li>Sec.&nbsp;3.3.1 (p.33): Should it really be &raquo;...to provide a message for sending unsolicited...&laquo; or should it rather be &raquo;... to provide a method for sending unsolicited...&laquo;?
</p>
<p><li>Sec.&nbsp;3.3.1 (p.33): Shouldn't it be &raquo;The "ORGANIZER"
property MUST be specified...&laquo;?
</p>
<p><li>Sec.&nbsp;3.3.2 (p.35): The comment for ATTENDEE sounds
wrong. What is it supposed to mean?
</p>
<p><li>Sec.&nbsp;3.3.3 (p.36): Remove the parentheses in the
comment for ATTENDEE and URL.
</p>
<p><li>Sec.&nbsp;3.3.3 (p.36): Remove &raquo;Multiple instances are
allowed.&laquo; in the FREEBUSY comment, since &raquo;0+&laquo; already says this.
</p>
<p><li>Sec.&nbsp;3.3.3 (p.36): Why is the sorting a MUST for PUBLISH,
while the introduction in Sec.&nbsp;3.3 only speaks of SHOULD?
</p>
<p><li>Sec.&nbsp;3.3.3 (p.36): Add comment for UID (like for VEVENT):
&raquo;MUST be the UID of the original REQUEST&laquo;
</p>
</ol>

<h2><a name="id17">Methods for VTODO Components</a></h2>
<ol start=53> <li>
<p>All restriction tables list the PRIORITY property as required for to-dos, while rfc2445bis does not mention any such restriction. I don't think PRIORITY is important enough to warrant a MUST in iTIP.
</p>
<p><li>Sec.&nbsp;3.4.1 (p.38): Why are Attendees forbidden with PUBLISH?
</p>
<p><li>Sec.&nbsp;3.4.1 (p.39), Sec.&nbsp;3.4.2 (p.41), Sec.&nbsp;3.4.4 (p.47), Sec.&nbsp;3.4.7 (p.53) and Sec.&nbsp;3.4.8 (p.55): In the STATUS comment, it should be IN-PROCESS (delete space), similarly it should be NEEDS-ACTION (insert hyphen)
</p>
<p><li>Sec.&nbsp;3.4.2 (p.39): Only the meaning of REQ-PARTICIPANT is explained. Are other values allowed? If so, what do they mean in connection with to-dos?
</p>
<p><li>Sec.&nbsp;3.4.2.2 (p.42): If the REQUEST is only used to "reconfirm" the to-do, do the Attendees still have to REPLY, even if nothing has changed? Or should they simply use the value of their RSVP ATTENDEE parameter to decide?
</p>
<p><li>Sec.&nbsp;3.4.2.3 (p.42): Why can't a to-do be delegated to the Organizer?
</p>
<p><li>Sec.&nbsp;3.4.2.4 (p.43): Same as <a href="#TODO_Forwarding_OrganizerResponse">*</a> for VEVENT.
</p>
<p><li>Sec.&nbsp;3.4.3 (p.44): What exactly is an &raquo;unsuccessful "VTODO" calendar component "REQUEST" method&laquo;? 
</p>
<p><li>Sec.&nbsp;3.4.3 (p.43): The same comment about properties that MUST NOT be changed should be inserted as for VEVENT (issue <a href="#VEVENT_NotChanged">*</a>) on p.23 right before the table.
</p>
<p><li>Sec.&nbsp;3.4.3 (p.44f): The UID comment should be moved to the ATTENDEE property, which it actually describes, and ATTENDEE should be changed from &raquo;1+&laquo; to &raquo;1&laquo; (see also the VEVENT REPLY table on p.23). The new UID comment should be &raquo;MUST be the UID of the original REQUEST&laquo;
</p>
<p><li>Sec.&nbsp;3.4.3 (p.45): If the VTODO in the REQUEST contained a VALARM, should this not be included in the REPLY, too?
</p>
<p><li>Sec.&nbsp;3.4.5 (p.48): &raquo;When a VTODO is cancelled&laquo; Does this mean only when the whole VTODO (with all its recurrence instances) is cancelled, or does it mean whenever a CANCEL is sent, in particular also when only a single ATTENDEE is unassigned? The same holds for VEVENT (p.26).
</p>
<p><li>Sec.&nbsp;3.4.5 (p.52): Since the RECURRENCE-ID is a date-time, it can include a reference to a timezone. In this case, a VTIMEZONE is REQUIRED.
</p>
<p><li>Sec.&nbsp;3.4.7 (p.52): The second sentence of the first paragraph is redundant, since the first sentence already says that the counterproposal is submitted to the Organizer.
</p>
<p><li>Sec.&nbsp;3.4.7 (p.52): If the counterproposal only contains some minor modifications (e.g. correcting typos in the description), does the Organizer still have to send the REQUEST to all Attendees and set RSVP=TRUE?
</p>
<p><li>Sec.&nbsp;3.4.7 (p.52): Remove the &raquo;;&laquo; after "ATTENDEE" property
</p>
<p><li>Sec.&nbsp;3.4.7 (p.53): In the comment for RECURRENCE-ID remove the spurious &raquo;3.5&laquo;
</p>
<p><li>Sec.&nbsp;3.4.8 (p.55): What does the comment for ATTENDEE mean? Does it mean that in a DECLINECOUNTER the Organizer has to insert all original Attendees?
</p>
</ol>

<h2><a name="id18">Methods for VJOURNAL Components</a></h2>
<ol start=71> <li>
<p>Sec.&nbsp;3.5.1 (p.57): What is the &raquo;original SEQUENCE number&laquo; in the comment for SEQUENCE for a PUBLISH of a VTODO? I would delete that first sentence.
</p>
<p><li>Sec.&nbsp;3.5.3 (p.61): VJOURNAL does not allow ATTENDEE, so the presence should be changed to &raquo;0&laquo; from &raquo;0+&laquo;.
</p>
</ol>

<h2><a name="id19">Status Replies</a></h2>
<ol start=73> <li>
<p>Sec.&nbsp;3.6 (p.62, item 2. A. and B.) I propose to exchange rules A. and B., delete the last sentence from the current B., and start the current A. with &raquo;Otherwise, if any one component&laquo;. This makes the logic much clearer.
</p>
<p><li>Sec.&nbsp;3.6 (p.62ff, column &raquo;Offending Data&laquo;): The comments in the &raquo;Offending Data&laquo; column speak about specifying the offending data, but don't make it clear where to specify it. I suppose the idea is to give the offending data in the extdata part of the status message, right? Maybe this could be clarified in a sentence before the table.
</p>
<p><li>Sec.&nbsp;3.6 (p.64, Code 5.0): What does the Return Status Description &raquo;Request MAY supported.&laquo; mean? (It is grammatically wrong, too.) In particular, the Offending Data column speaks about the METHOD (should be written in all-capitals) property 
</p>
</ol>

<h2><a name="id20">Implementation Considerations</a></h2>
<ol start=76> <li>
<p>Sec.&nbsp;3.7.1 (p.65): In the second paragraph it should be &raquo;discrete&laquo; instead of &raquo;discreet&laquo;
</p>
<p><li>Sec.&nbsp;3.7.1 (p.66): In the last paragraph of this section it should be &raquo;or to-do has been made&laquo; (instead of &raquo;has be made&laquo;)
</p>
<p><li>Sec.&nbsp;3.7.1 (p.66): The last three sentences of this section 
(discussing RECURRENCE-ID) are plain wrong. In particular, they are in
contradiction to Sec.&nbsp;3.8.4.4 of rfc2445bis: The RECURRENCE-ID 
is always the start date of the original recurrence instance, even 
after the change has been made. As an example, take an event 
recurring each Monday at 9:00. One of these meetings is moved to 
12:00 and its LOCATION is changed. Even after the change has been 
propagated to the Attendees, the RECURRENCE-ID of that event will 
still be YYYYMMDDT090000, otherwise the recurrence rule would generate an 
additional event at 09:00 and a RECURRENCE-ID of YYYYMMDDT120000 
does not appear in the recurrence set either. This is clearly 
explained in rfc2445bis (Sec.&nbsp;3.8.4.4, p.116) using the Friday to 
Thursday change. The RECURRENCE-ID stays on the original date.
</p>
<p><li>Sec.&nbsp;3.7.3 (p.67): This draft allows clients to completely 
ignore X-Tokens. Granted, for REPLY, REFRESH etc. there is 
no advantage in preserving them (because the Attendee's CUA doesn't
handle them anyway and the Organizer already has their value), but 
when delegating or forwarding calendar components, the Other CU 
might be interested in the X-Tokens, because his CUA might know how 
to handle them.
</p>
</ol>

<h1><a name="id21">Examples</a></h1>
<h2><a name="id22">Published Event Examples</a></h2>
<ol start=80> <li>
<p>Sec.&nbsp;4.1 (p.67): In the first paragraph, change &raquo;e- mailing&laquo; 
to &raquo;e-mailing&laquo; (remove space) and replace &raquo;and posting&laquo; by 
&raquo;or posting&laquo; to make it clearer that this enumeration is not 
exhaustive and PUBLISH can be used in other ways, too.
</p>
</ol>

<h2><a name="id23">Group Event Examples</a></h2>
<ol start=81> <li>
<p>Sec.&nbsp;4.2 (p.71): In the table change &raquo;tentative&laquo; to &raquo;TENTATIVE&laquo;. According to rfc2445bis Sec.&nbsp;3.1 and 3.2 enumerated property values are case-insensitive, but rfc2445bis and rfc2446bis consistently uses all-capitals for enumerated parameter values.
</p>
<p><li>Sec.&nbsp;4.2.1 (p.72): The explanation details the default value 
for PARTSTAT and when it can be left out, but does not mention that 
the same also holds for CUTYPE=INDIVIDUAL, which could also be left 
out in the example
</p>
<p><li>Sec.&nbsp;4.2.1 (p.72): The DTSTART and DTEND coincide. Sec.&nbsp;3.8.2.2 of rfc2445bis says that the DTEND MUST be later in time than DTSTART! Also, how much sense does a 
Conference of 0 seconds make?
</p>
<p><li>Sec.&nbsp;4.2.2 (p.73) and Sec.&nbsp;4.2.4 (p.76): As explained in issue <a href="#DTSTART_Absent">*</a> above, 
rfc2445bis REQUIRES DTSTART to be present in a VEVENT, while the 
REPLY, REFRESH and DECLINECOUNTER methods defined in this draft forbit
it. These examples are not valid iCalendar objects as specified by 
rfc2445bis. The same holds of course for all further REPLY, REFRESH and 
DECLINECOUNTER examples.
</p>
<p><li>Sec.&nbsp;4.2.4 (p. 74f): The description says that the given counter-proposal 
also changes the location, but the LOCATION property value 
is the same in the REQUEST and the COUNTER.
</p>
<p><li>Sec.&nbsp;4.2.4 (p.75): The counter-proposal contains the DTSTAMP
property twice. According to the restrictions table in 
Sec.&nbsp;3.2.7 and the VEVENT definition in Sec.&nbsp;3.6.1 on 
page 54 of rfc2445bis this is not allowed.
</p>
<p><li>Sec.&nbsp;4.2.5 (p.76): The second to fourth items of the list 
should be further indented, since they are actually subitems of 
the first list item.
</p>
<p><li>Sec.&nbsp;4.2.5 (p.76): The last item in the list actually 
contradicts what is said in Sec.&nbsp;3.2.2.3 (p.20), namely that 
the delegator MUST add an "ATTENDEE" property describing the 
Delegate to the REQUEST that he sends to the Delegate. Thus, he 
definitely MUST NOT send a copy of the original REQUEST, but 
rather a  slightly modified one.
</p>
<p><li>Sec.&nbsp;4.2.10 (p.82): In the table replace &raquo;Remove an "B" as&laquo; by &raquo;Remove "B" as&laquo;.
</p>
<p><li>Sec.&nbsp;4.2.10 (p.82): In the table it is not clear to me 
whether it is a requirement for the Organizer to send the updated 
event to the remaining Attendees after B was cancelled or not. The
table describes just one cause of action, but from the definitions
in Chapter 3, it is also not clear to me whether the Organizer 
MAY/SHOULD/MUST send a new REQUEST to all remaining Attendees 
after one Attendee was cancelled.
</p>
</ol>

<h2><a name="id24">Busy Time Examples</a></h2>
<ol start=91> <li>
<p>Sec.&nbsp;4.3 (p.84): Before &raquo;Individual A publishes busy time for 
one week&laquo;, a subsection header &raquo;4.3.1  Publish Busy Time&laquo; should 
be inserted for consistency (all other METHODS have their own 
subsection)
</p>
<p><li>Sec.&nbsp;4.3 (p.85): The description of the example says that 
busy time for one week was published, but the period specified by 
DTSTART and DTEND actually is only 6 days! Furthermore, the 
VFREEBUSY contains FREEBUSY property values that start way beyond 
the DTEND. rfc2445bis says in Sec.&nbsp;3.6.4 on p.63 that for published 
busy time the &raquo;DTSTART and DTEND properties specify an inclusive 
time window that surrounds the busy time information&laquo;. In other words,
all FREEBUSY periods MUST be inside the interval specified by 
DTSTART and DTEND.
</p>
</ol>

<h2><a name="id25">Recurring Event and Time Zone Examples</a></h2>
<ol start=93> <li>
<p><a name="RRULE_INTERVAL"> Sec.&nbsp;4.4.1</a> (p.87): The description says that this event is 
for a weekly phone conference, but the RRULE uses INTERVAL=20, which 
means that the event recurs every 20 weeks! The correct RRULE would be
</p>
<pre>
    RRULE:FREQ=WEEKLY;COUNT=20;WKST=SU;BYDAY=TU</pre>
<p>I blame this on the ambiguous formulation in rfc2445bis: In 
Sec.&nbsp;3.3.10 on p.40 it says &raquo;The INTERVAL rule part contains 
a positive integer representing how often the recurrence rule 
repeats.&laquo; Of course, it is supposed to be interpreted in the 
sense "in which intervals the r.r. repeats", but can admittedly 
also be read as "how many times the r.r. repeats". Apparently 
this was not clear to the person who included this example in 
rfc2446.
</p>
<p><li>Sec.&nbsp;4.4.1 (p.88): The paragraph describing the representation of the times in different time zones contains several issues / confusions:
</p>
<ol> <li>
<p>The time zone difference for Attendee "b" is expressed as the 
offset from PDT, while the time zone difference for Attendee 
"c" is given as the offset from UTC, which makes  comparing 
these two times much harder. 
</p>
<p><li>In the explicit time listings below, "GMT" is used 
instead of "UTC". 
</p>
<p><li>JST is 9 hours ahead of UTC, not 8 hours as claimed here.
</p>
<p><li>On November 11, 1997, San Jose is no longer in PDT, but in PST.
</p>
<p><li>On Wed, September 10, 1997, San Jose is still in PDT, not 
in PST as claimed.
</p>
<p><li>The representation of the exception dates in the other 
time zones are calculated wrong: 14:00 PDT on Sept 9 is NOT 
23:00 GMT (=UTC), but rather 23:00 CEST or 21:00 UTC. Similarly, 
14:00 PST (=UTC-8) on Oct 28 is 22:00 UTC or 23:00 CET or 07:00 
JST (UTC+9), not 06:00 JST!
</p>
</ol>
<p>I would give all times offsets relative to PDT and list the local time zones and all local times mentioned together with their shift from UTC.
In the list of exceptions, I would also list the PDT/PST date/times 
first, as they are the real exception dates, the representation in 
UTC and JST just helps the user to understand the issues with 
time zones.
</p>
<p>All in all, I think that paragraph should be:
</p>
<pre>
   The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT 
   (UTC-7). "Attendee" [email-masked] is in France where the local time 
   on this date is 9 hours ahead of PDT or 23:00 CEST (UTC+2). 
   "Attendee" [email-masked] is in Japan where local time is 16 hours 
   ahead of PDT or Wednesday, July 2 at 06:00 JST (UTC+9).  The event 
   repeats weekly on Tuesdays (in PST/PDT). The "RRULE" property results 
   in 20 instances. The last instance falls on Tuesday, November 11, 
   1997 2:00pm PST. The "RDATE" property adds another instance: 
   WED, 10-SEP-1997 2:00 PM PDT.

   There are also two exception dates to the recurrence rule. The first one
   is:

   TUE, 09-SEP-1997 14:00 PDT (UTC-7)
   TUE, 09-SEP-1997 23:00 CEST (UTC+2)
   WED, 10-SEP-1997 06:00 JST (UTC+9)

   and the second is:

   TUE, 28-OCT-1997 14:00 PST (UTC-8)
   TUE, 28-OCT-1997 23:00 CET (UTC+1)
   WED, 29-OCT-1997 07:00 JST (UTC+9)
  </pre>
<p><li><a name="ADD_Recurrence"> Sec.&nbsp;4.4.7</a> (p.93f): It would be very helpful if the comments 
included an explanation how the added times are added to the original VEVENT. In particular, a single event is added by adding its DTSTART as an RDATE to the original event, possibly with another VEVENT using RECURRENCE-ID to modify some of its properties if the properties of the ADD differed from the original event.
Similarly, another recurring event can be added by either modifying the existing RRULE or adding a second RRULE (however, rfc2445bis deprecates the use of two RRULEs for a calendar component!). However, it is not clear how one should proceed if the added recurring event differs from the original event (e.g. has a different LOCATION like the second example of this section). As explained in <a href="#ADD_Explanation">*</a>, the 
second example adds another recurrence rule to an event with an already
existing recurrence rule, but the added event has a different LOCATION than the original event. The PUBLISH example, which is claimed to be equal to the REQUEST and the subsequent ADD, however, ignores this changed LOCATION property value and only uses the LOCATION property value of the original event. It should be clarified if changed property values in the ADD should really be ignored or not. If not, this case with an added recurrence needs to be explained further (whether and how it can be represented in iCalendar at all!).
</p>
<p><li>Sec.&nbsp;4.4.9 (p.100): The REPLY contains a REQUEST-STATUS with status code 3.0 and one with code 2.8. However, the previous explanation of REQUEST-STATUS in Sec.&nbsp;3.6 expressively forbids any non-3.x code if a 3.x code is already present. Thus, the 2.8 code entry should be deleted from the event.
</p>
</ol>

<h2><a name="id28">Group To-do Examples</a></h2>
<ol start=97> <li>
<p>Sec.&nbsp;4.5.1 (p.102): The STATUS property value should be NEEDS-ACTION (Hyphen is missing; enumerated property values are case-insensitive, still I think we should use all-capitals consistently)
</p>
<p><li>Sec.&nbsp;4.5.6 (p.104): The STATUS property value should be IN-PROCESS rather than the invalid IN-PROGRESS
</p>
<p><li>Sec.&nbsp;4.5.7 (p.105): Time zones cannot be given as -0700, so I think DTSTART and DUE should be 
</p>
<pre>
    DTSTART:19980101T170000Z
    DUE:19980103T170000Z</pre>
<p>Additionally, the STATUS property value should be NEEDS-ACTION (hyphen missing)
</p>
<p><li>Sec.&nbsp;4.5.7.2 (p.105): This section talks about how recurrence works in general for to-dos, which would much better belong in rfc2445bis rather than rfc2446bis. So I think this whole section should be moved to rfc2445bis.
Also, this section speaks of the due date specified in a "REQUEST", while of course the same holds true for PUBLISH, ADD, COUNTER, etc., too. It is not even specific to iTIP, but rather a general issue in iCalendar. The reference to REQUEST should at least be deleted.
</p>
</ol>

<h2><a name="id29">Journal Examples</a></h2>
<ol start=101> <li>
<p>Sec.&nbsp;4.6 (p. 106): The example is missing the REQUIRED DTSTAMP property.
</p>
</ol>

<h2><a name="id30">Other Examples</a></h2>
<ol start=102> <li>
<p>Sec.&nbsp;4.7.1 (p.107): In the describing text the UID value is line-broken, which should not happen.
</p>
<p><li><a name="UID_space"> Sec.&nbsp;4.7.1</a> (p.107): While rfc2445bis allows spaces in the UID, it's not clear to me whether those spaces are actually part of the UID. In particular, are the following two UID property lines equivalent?
</p>
<pre>
    UID:[email-masked]
    UID: [email-masked]
</pre>
<p>rfc2445bis defines the UID in Sec.&nbsp;3.8.4.7 to be of text type, which allows spaces, but is quiet on how UIDs should be compared. Reading rfc2445bis strictly, everything after the colon is part of the UID, so that the two lines above are NOT equivalent. The space should proably be deleted from this example, but rfc2445bis should also clarify this case whether spaces are allowed in UIDs and whether leading/trailing spaces should be ignored.
</p>
<p><li>Sec.&nbsp;4.7.2 (p.107): The second sentence speaks about the case when &raquo;an "Organizer" sends a request&laquo;, which is an unfortunate wording, because it applies not only to the REQUEST method, but to any iTIP message sent. I would replace &raquo;a request&laquo; by &raquo;an iTIP message&laquo;.
</p>
<p><li>Sec.&nbsp;4.7.2 (p.107): In the explanation for case (1), the case where the SEQUENCE number was incremented by 1 is not a problem and does not mean that the Attendee missed a message or is receiving an out-of-sequence message. Rather is the default case when the Organizer modifies a calendar component: He will increase the SEQUENCE number by 1 and send out a new REQUEST to the Attendees. Thus this case should be not be covered by this case. If the CU receives a REQUEST where the SEQUENCE number is 1 larger than his current version and the RECURRENCE-ID can not be found in his calendar component, that's a worse case, since apparently he received all changes, which do, however, not contain that specific recurrence instance. Only for the CANCEL method the problem arises as described in case (2).
</p>
<p><li>Sec.&nbsp;4.7.2 (p.108): In the explanation for case (3), I think the Attendee SHOULD/MUST send a response with the status code &raquo;2.8; Success, repeating event ignored. Scheduled as a single component&laquo;. If he should not send such a reply (since he has probably already sent it when he received the original REQUEST that sets the recurrence), it should be mentioned here explicitly.
</p>
<p><li>Sec.&nbsp;4.7.2 (p.108): The table and the example cover only case (2), so it should either be moved to the text for (2) or the text above the table should explicitly mention that it covers case (2).
</p>
</ol>

<h1><a name="id32">Application Protocol Fallbacks</a></h1>
<ol start=108> <li>
<p>Between an &raquo;Ignore&laquo; and some following text in all the tables, the punctuation should be consistent. In some places there is a &raquo;,&laquo; after the &raquo;Ignore&laquo;, in some places a period &raquo;.&laquo; and in some places the text continues after only a space &raquo; &laquo;.
</p>
<p><li>Sec.&nbsp;5.1.1 (p. 110): If a CUA does not support recurrences, it cannot handle ADD by default. There should be a fallback for this case, probably to insert the ADDed event as a separate component and replying with status code &raquo;2.8; Success, repeating event ignored. Scheduled as a single component&laquo;.
</p>
<p><li>Sec.&nbsp;5.1.1 (p.110): PRODID and VERSION are REQUIRED for rfc2445bis support, which rfc2446bis relies upon. Still, I agree it does not hurt if a CUA ignores PRODID and/or VERSION, so this can be left unchanged, too. I just wanted to point out that it's already a requirement for rfc2445bis.
</p>
<p><li>Sec.&nbsp;5.1.1 (p.111), Sec.&nbsp;5.1.3 (p.113) and Sec.&nbsp;5.1.4 (p.116): In the ATTENDEE properties, remove &raquo;EVENT-&laquo;, &raquo;VTODO - &laquo; and &raquo;JOURNAL - &laquo;, since there is no method "EVENT-REQUEST" and the fact that this is for events is clear from the section header anyway. If you think it should be left in, it should at least be changed to &raquo;REQUEST for events&laquo; etc.
</p>
<p><li>Sec.&nbsp;5.1.1 (p.111) and Sec.&nbsp;5.1.3 (p.114): In the ATTENDEE properties, change &raquo;is not implemented&laquo; to the correct &raquo;is implemented&laquo;.
</p>
<p><li>Sec.&nbsp;5.1.1 (p.111): In the fallbacks for other calendar methods, there is no requirement to reply with &raquo;Not Supported&laquo; if the ATTENDEE property is not supported. Why is it a requirement for events?
</p>
<p><li>Sec.&nbsp;5.1.1 (p.111): Why is DESCRIPTION required? If an event has a SUMMARY, one can safely ignore the DESCRIPTION. On the other hand, many events I have seen have only a SUMMARY (which can be ignored according to the table), but no DESCRIPTION. It would make sense to me to treat SUMMARY and DESCRIPTION similarly.
</p>
<p><li>Sec.&nbsp;5.1.1 (p.111): I think the ORGANIZER property can only be ignored for PUBLISH, but not for any of the other methods, since that's the address where required replies must be sent to.
</p>
<p><li>Sec.&nbsp;5.1.1 (p.111): In the fallback for RRULE, change "DTStart" to "DTSTART", since the formatting conventions at the beginning of the draft say that all property names are in capitals.
</p>
<p><li>Sec.&nbsp;5.1.2 (p.112): Shouldn't there be a fallback for the case where the ATTENDEE property is not supported?
</p>
<p><li>Sec.&nbsp;5.1.2 (p.112): Why is DURATION support required for VFREEBUSY, when it is not required for VEVENT and VTODO?
</p>
<p><li>Sec.&nbsp;5.1.3 (p.113) and Sec.&nbsp;5.1.4 (p.116): RECURRENCE-ID should be changed to &raquo;Required if RRULE is implemented&laquo;, like it is for VEVENT.
</p>
<p><li>Sec.&nbsp;5.2.2 (p.117): This section talks only of delegation, but completely ignores that a REQUEST can be forwarded to another CU, who then replies to the Organizer. Additionally, the last sentence poses a possible privacy issue: If the CUA implements the first strategy lined out in the second-to-last sentence (&raquo;accept the reply&laquo;) and treats the REPLY as a REFRESH, it might automatically send the current version of an event to a person, who is not authorized to have that information.
</p>
</ol>

<h1><a name="id33">Security Considerations</a></h1>
<ol start=121> <li>
<p>Sec.&nbsp;6.1.5 (p.118): Why is this a "MAY" and not "may"?
</p>
<p><li>Sec.&nbsp;6.2 (p.118): Remove one of the duplicated &raquo;is subject&laquo;.
</p>
<p><li>Sec.&nbsp;6.2.2 (p.119): Procedure alarms were deprecated in rfc2445bis, so the sentence about their security issues can be deleted from rfc2446bis.
</p>
</ol>

<h1><a name="id34">IANA Considerations</a></h1><p>No comments.
</p>

<h1><a name="id35">Acknowledgments</a></h1><p>No comments.
</p>

<h1><a name="id36">Normative References</a></h1><p>No comments.
</p>

<h1><a name="id37">Appendices</a></h1><p>No comments.
</p>

<h1><a name="id38">Issues in rfc2445bis-08</a></h1>
<ol start=1> <li>
<p>Sec.&nbsp;"3.6.1.  Event Component" (p.54): Either make the DTSTART 
optional in rfc2445bis again or make it REQUIRED in the REPLY, REFRESH and DECLINECOUNTER methods in  rfc2446bis (currently, it MUST NOT be present for these methods).
</p>
<p><li>Sec.&nbsp;"3.6.5. Time Zone Component" (p.71): The text above the
example says that this is an example of a time zone using the
RDATE property. The example, however, does not contain any
RDATE.
</p>
<p><li>Sec.&nbsp;"3.8.7.4.  Sequence Number" (p.142): It should be clarified whether the SEQUENCE number
is supposed to be the same for all different components with the
same UID (but differing in their use of RECURRENCE-ID to identify
particular instances of a recurring sequence) or whether they can have different SEQUENCE numbers (see also issue <a href="#SEQUENCE_MultipleUID">*</a> above).
</p>
<p><li>Sec.&nbsp;"3.3.10.  Recurrence Rule" (p.40): As discussed in issue 
<a href="#RRULE_INTERVAL">*</a> for Sec.&nbsp;4.4 above, the description of 
INTERVAL can possibly be misunderstood. The next sentence explains 
it better, but it also only uses an interval of 1. Furthermore,
anyone who misunderstood the first, ambiguous sentence will not
be corrected by that second sentence. I propose to change the first
sentence to: 
</p>
<pre>
   The INTERVAL rule part contains a positive integer representing 
   at which intervals the recurrence rule repeats.</pre>
<p>Furthermore, I would add one more sentence to that paragraph:
</p>
<pre>
   A value of "2" means for example every other day for a DAILY rule, etc.</pre>
<p>This explains the use of INTERVAL much better than the default value of "1".
</p>
<p><li>Sec.&nbsp;"3.8.4.7.  Unique Identifier" (p.120f): As detailled in issue <a href="#UID_space">*</a> above, it should be clarified how spaces in a UID property value should be handled. In particular, are they allowed at all? Are leading or trailing spaces to be ignored when looking for or comparing UIDs?
</p>
</ol>
<hr />
</body></html>

--Boundary-00=_7xHxICeqGLWTPkk
Content-Type: text/x-tex;
  charset="iso 8859-15";
  name="Review_RFC2446bis_2008-09.tex"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Review_RFC2446bis_2008-09.tex"

\documentclass[a4paper,11pt]{article}
\usepackage[pdftex]{hyperref}
\usepackage{url}
\usepackage{geometry}
\usepackage[english]{babel}
\usepackage{enumitem}
\usepackage{hyperlatex}
\setcounter{htmldepth}{0}

\texonly{
\geometry{left=2cm,right=2cm,bottom=2.5cm}
\hypersetup{
colorlinks=true,
pdftitle=IETF Review of the RFC 2446bis-07 (iTIP) draft,
pdfauthor=Reinhold Kainhofer <[email-masked]>
} 
}

% Title Page
\title{\textbf{IETF Review of the RFC 2446bis-07 draft:\\iCalendar Transport-Independent Interoperability Protocol (iTIP)}}

\texonly{
  \author{Reviewer: Reinhold Kainhofer, \[email-masked]}}
}
\htmlonly{
  \author{Reviewer: \xlink{Reinhold Kainhofer}{mailto:[email-masked]}}
  \htmltitle{IETF Review of the RFC 2446bis-07 (iTIP) draft}
}
\date{September 7, 2008}
\newcommand{\rfcquote}[1]{\texorhtml{\guillemotright}{\xmlent{raquo}}{#1}\texorhtml{\guillemotleft}{\xmlent{laquo}}}
\htmlonly{
  \renewcommand{\pagebreak}{}
}

\begin{document}
\maketitle

\texonly{
  \tableofcontents
}
\texonly{
  \pagebreak
}

\section*{About this review}
\addcontentsline{toc}{section}{About this review}

Since this draft is an update to an already existing standard, I will
not comment on its usefulness in general, but rather concentrate on technical
details. In particular, I looked at possible contradictions to
rfc2445bis-08, unclear explanations,
formulations that might possibly be misunderstood, and typos. The
page-breaking of the draft is also not ideal, but I suppose this
will be fixed in the final release, so I will not further comment on it.
Even though several of the issues I found were already detailled in
Lisa Dusseault's review, I will still list them here.

I will go through the whole draft section by section, mixing comments of
different types, like errors, unclear formulations, other suggestions
and questions I still have, etc.
I will use one item per issue I found, even when I found multiple
issues in a section. This will make it easier to discuss the issues.

Quotes from the draft and rfc2445bis as well as text to be 
inserted into the draft will be placed in \rfcquote{guillemets} to 
destinguish them from text in quotations marks in the draft (like 
all property and method names).

\section*{General observations}
\addcontentsline{toc}{section}{General observations}

\begin{enumerate}
  \item The capitalization of \rfcquote{event} is inconsistent throughout
  the draft. Sometimes, \rfcquote{Event} is used inside a sentence, at other
  times \rfcquote{event} is used.

\end{enumerate}

\section{Introduction and overview}

\begin{enumerate}[resume]

  \item Abstract (p.1): \rfcquote{calendar systems} should be replaced by \rfcquote{calendaring systems} to prevent any possible confusion. iTIP is only about the Gregorian calendar system.
  \item Sec.~1.3 (p.6): This draft also describes forwarding, where
  there is a third role involved, namely "Other CUs". Also, when
  delegating, the delegate is not an \rfcquote{"Attendee" asked to participate
  by the "Organizer"}, so it does not strictly fulfill the definition
  of the Attendee role of section 1.3., either.
  \item Sec.~1.3 (p.7): The definition of the Attendee uses \rfcquote{participate}, which does not make sense for to-dos.
  \item Sec.~1.4 (p.7): In the REQUEST Description: Change \rfcquote{Meeting Requests} to \rfcquote{Meeting requests}
  \item Sec.~1.4 (p.8): Why are Attendees not allowed to PUBLISH a group event?

\end{enumerate}

\section{Interoperability Models}
\begin{enumerate}[resume]

  \item Sec.~2.1.1 (p.9): \rfcquote{When an "Organizer" issues the initial
  entry, "Attendee" status is unknown.} The Organizer might have had other
  communication with the Attendee and already know the status
  from other means than iTIP. I would insert the word \rfcquote{typically}
  before \rfcquote{unknown}.
  \item Sec.~2.1.4 (p.10f): This section heavily refers to the rules
  for incrementing the "SEQUENCE" number in [I\_D.ietf-calsify-rfc2445bis].
  However, rfc2445bis-08 only says: \rfcquote{It is monotonically
  incremented by the "Organizer's" CUA each time the "Organizer"
  makes a significant revision to the calendar component.}
  The rest of the rules was removed from rfc2445bis in rfc2445bis-08,
  but has not been added to rfc2446bis. I propose to remove all
  references to rfc2445bis in this section and instead paste the
  rules into rfc2446bis:
  \begin{verbatim}
   The "SEQUENCE" property is used by the "Organizer" to indicate
   revisions to the calendar component. When the "Organizer" makes
   changes to one of the following properties, the sequence number
   MUST be incremented:
      *  "DTSTART"
      *  "DTEND"
      *  "DURATION"
      *  "DUE"
      *  "RDATE"
      *  "RRULE"
      *  "EXDATE"
      *  "STATUS"

   In addition, changes made by the "Organizer" to other properties
   MAY also require the sequence number to be incremented.  The
   "Organizer" CUA MUST increment the sequence number whenever it
   makes changes to properties in the calendar component that the
   "Organizer" deems will jeopardize the validity of the
   participation status of the "Attendees".  For example, changing
   the location of a meeting from one location to another distant
   location could effectively impact the participation status of the
   "Attendees".

   Depending on the METHOD, the "SEQUENCE" property MUST follow
   these rules in the context of iTIP:
     * For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE"
       property value is incremented according to the rules stated
       above.
     * The "SEQUENCE" property value MUST be incremented each time the
...  [rest is taken as found in rfc2446bis-07] ...
  \end{verbatim}

  \item \label{SEQUENCE_MultipleUID}Sec.~2.1.5 (p.11/12): From this description, it appears
  to me that all calendar components with the same UID also need
  to have the SEQUENCE incremented simultaneously (i.e. if the Organizer changes just one
  occurrence from a recurring sequence, he must increase the
  SEQUENCE not only of that particular VEVENT, but also of the
  VEVENT containing the RRULE). This was not clear to me from
  rfc2445bis and is never clearly spelled out. In particular,
  rfc2445bis says on page 142 that \rfcquote{SEQUENCE defines the revision
  sequence number of the calendar component within a sequence of
  revisions} and defines calendar component on pages 52ff as
  any VEVENT, VTODO, VJOURNAL, etc. inside the VCALENDAR.
  In particular, a VEVENT with
  an RRULE and another VEVENT with the same UID, but using
  RECURRENCE-ID to modify one single instance of the recurrence,
  are actually two calendar components, as far as I understand
  the wording. The description of SEQUENCE can then be understood
  that both can have different SEQUENCE numbers...

  This should probably be clarified in rfc2445bis.

  If, however, it is possible for the two components to have
  different SEQUENCE numbers, then items 3. and 4. of the list in
  section 2.1.5 need to be changed from \rfcquote{UID} to \rfcquote{UID and
  RECURRENCE-ID}.

  \item Sec.~2.1.5 (p.12): \rfcquote{Hence, CUAs must persist} should rather
  be \rfcquote{Hence, CUAs MUST persist}

  \item Sec.~2.1.5 (p.12): I don't understand what is meant with the
  sentence \rfcquote{Furthermore, for each "ATTENDEE" property of a component
  CUAs must persist the "SEQUENCE" and "DTSTAMP" property values
  associated with the "Attendee's" response.} First, I don't understand
  the meaning: Does this mean that the Organizer's CUA needs to store
  for each Attendee the last SEQUENCE number, to which the Attendee has
  responded? In this case, I don't understand the reason behind it.
  Or does it mean that the Attendee's CUA needs to preserve the
  SEQUENCE of his/her last response, so that it's possible to decide
  whether a response to a new REQUEST from the Organizer is needed.
  In that case, I don't think that sentence is needed, either,
  because it is stated in the draft already that only the Organizer
  is allowed to make changes to a component.
  Also, which CUAs are meant: The CUA of the Organizer or of the Attendee?

\end{enumerate}

\section{Application Protocol Elements}
\begin{enumerate}[resume]

  \item Sec.~3 (p.12, methods table): From the VJOURNAL column,
  it seems to me that CANCEL and ADD can also be used change
  components that were PUBLISHed, not only REQUESTed ones.
  This is never clearly spelled out, in particular not for VEVENT
  and VTODO.
  \item All the restriction tables in this chapter list the
  VALARM component parallel to VEVENT, VTODO, VJOURNAL and VFREEBUSY.
  I regard this as quite unfortunate, because VALARM is not a top-level
  calendar component, but can only appear inside other components.
  As the description of the tables says that component properties
  are indented, I think it would make sense to also indent VALARM,
  which is a component component.
  \item \label{DTSTART_Absent}Several of the constraint tables for VEVENT in chapter 3
  either disallow DTSTART at all or allow DTSTART to be absent
  from a component. In particular, the VEVENT REFRESH (Sec.~3.2.6, p.28)
  and DECLINECOUNTER (Sec.~3.2.8, p.31) tables disallow DTSTART at
  all, while VEVENT CANCEL (Sec.~3.2.5, p.27), allow \rfcquote{0 or 1} DTSTART.
  In contrast, rfc2445bis (Sec.~3.6.1, p.54) REQUIRES DTSTART to
  be present in all VEVENT components, so that e.g. the contents
  of a REFRESH are NOT VALID iCalendar! Notice, that this restriction
  in rfc2445bis was not in rfc2445, but was added during the update 
  to rfc2445bis.

\end{enumerate}

\subsection{Common Component Restriction Tables}
\begin{enumerate}[resume]

  \item Sec.~3.1.2 (p.14, VTIMEZONE table): This table states that
  RRULE and RDATE MUST NOT both be present at the same time.
  rfc2445bis does not have such a restriction, so that some
  VTIMEZONE objects, which are valid in rfc2445bis, cannot be
  used for group scheduling. I propose to remove that restriction.

\end{enumerate}

\subsection{Methods for VEVENT Calendar Components}
\begin{enumerate}[resume]

  \item Sec.~3.2 (p.15, methods table, REQUEST): \rfcquote{Event requests}
  instead of \rfcquote{Event Requests}. Also, I think it should be
  \rfcquote{MAY degrade} instead of \rfcquote{may degrade}.
  \item Sec.~3.2.1 (p.16): I have never understood why a PUBLISHed
  event MUST NOT have any Attendees. In particular, I think it
  might be useful for several types of published events to contain
  Attendees and their participation status: panel discussions,
  hearings, etc.
  \item \label{REQUEST_privacy_all_attendees}Sec.~3.2.2 (p.16ff):
  Is there any requirement that the VEVENT REQUEST
  sent out to one particular Attendee MUST/SHOULD contain
  all other Attendees? Cf. in particular Sec.~3.2.5 (see issue
  \ref{CANCEL_privacy_all_attendees}), which states
  that a cancelled event MUST include all Attendees. In my opinion,
  there should not be such a requirement, mainly for privacy reasons.
  The attendees' email addresses are explicitly listed in the
  ATTENDEE property, so I don't regard it a good idea that all
  attendees automatically learn about the email addresses of all
  other attendees, which might be well-known persons and quite
  reluctant to give out their private contact details.
  In any case, a sentence should be inserted clarifying whether
  all attendees MUST/SHOULD be given in the VEVENT, or whether it
  is possible to send individual requests to each attendee containing
  only the one ATTENDEE property for this particular person.
  \item Sec.~3.2.2 (p.17): The paragraph after the list is not
  true for delegated and forwarded events.
  In particular, in both cases the recipients are not the
  "Attendees", but "Other CUs".
  \item Sec.~3.2.2.3 (p.21): In the second-to-last paragraph,
  there is a spurious " between method and SHOULD.
  \item Sec.~3.2.2.3 (p.20/21): The delegator forwards the REQUEST
  to the delegate, including the delegate as a new ATTENDEE. The
  delegator also sends a REPLY to the Organizer with the DELEGATED-TO
  parameter set. However, it is not clear to me whether the REPLY to
  the organizer MUST/SHOULD also contain the delegate as a new ATTENDEE
  or not. As the comment in Sec.~4.2.5 says this is a MUST, 
  it should be added here, too, since here is the section where 
  delegating is actually defined. The examples -- helpful as they 
  are -- should not include any new requirements not described 
  before.
  \item Sec.~3.2.2.4 (p.21): In the last sentence, it should read
  \rfcquote{... incremented and the value of ...}.
  \item Sec.~3.2.2.4 (p.21): The last sentence says that \rfcquote{the
  "ORGANIZER" property has been changed to the \emph{calendar address}
  of the new "Organizer".} However, rfc2445bis defines the calendar
  address as only the URI and does not include property
  parameters like CN, which should clearly be changed, too.
  I think it would suffice to simply say \rfcquote{and the value of the
  "ORGANIZER" property has been changed to the new "Organizer".}
  \item Sec.~3.2.2.6 (p.21): There is one step missing in the
  description: The Attendee forwards to the uninvited CU, but there
  is no mentioning of how the Organizer learns of this.
  \item \label{TODO_Forwarding_OrganizerResponse} Sec.~3.2.2.6 (p.21): How does the uninvited CU find out whether
  the Organizer added him/her or not. The draft only says that the
  Organizer MAY send a CANCEL if he rejects the new Attendee. However,
  if he does not, then the uninvited Attendee has no way of knowing
  whether he was added or not. A sentence should be added clarifying
  this situation. Should the uninvited CU simply send a REFRESH to
  the organizer? If he does not get a response there either, he can
  deduce that he was not added (see Sec.~6.1.6).
  \item Sec.~3.2.2.6 (p.22): The last sentence says that the Attendee
  MUST NOT make changes to the VEVENT property set. However, this would
  not prohibit changes to other calendar components, like VTIMEZONE,
  VALARM, etc. I don't think such changes should be allowed, either.
  \item Sec.~3.2.3 (p.22): Should \rfcquote{An "Attendee" can include} rather
  be \rfcquote{An "Attendee" MAY include}?
  \item \label{VEVENT_NotChanged} Sec.~3.2.3 (p.23): This section says that the optional
  properties listed in the table MUST NOT be changed. However,
  the rest of the draft and the comments in the table make it clear
  that some required parameters (DTSTAMP, UID, ORGANIZER) MUST also
  NOT be changed.
  \item Sec.~3.2.3 (p.24): The table lists VALARM as \rfcquote{0}. If the
  original REQUEST contained a VALARM, shouldn't it be included in
  the REPLY, too?

  \item \label{ADD_Explanation} Sec.~3.2.5 (p.24f): 
  I don't understand
  how ADD should work exactly. rfc2445bis says that an instance of
  an event is identified by the UID and the RECURRENCE-ID. If we
  don't allow a RECURRENCE-ID, how does the resulting sequence
  of events look in iCalendar notation (i.e. what would the
  Organizer send in response to a REFRESH)?

  I suppose it would work to add the additional date as an RDATE
  or a second RRULE, but only if none of the other properties
  is different from the original event. Sec.~4.4.7 gives an
  example of this case (but since it does not point out that an
  RDATE was added, it is very hard to figure out how the
  ADD was handled). If some properties are different for a single
  ADDed event, this can still be represented as an added RDATE
  and a second VEVENT using RECURRENCE-ID to specify the added
  instance. However, if an ADD message tries to add a recurring
  event with some property values different from the original
  (already recurring) event, then I simply don't see how this can
  be represented in iCalendar.
  RECURRENCE-ID;RANGE=THISANDFUTURE can not be used, because the
  change should only apply to the instances of one RRULE, not of both.
  
  An example of this problem is the first example in Sec.~4.4.7:
  The original RRULE recurs on TU in \rfcquote{The White Room}. The ADD
  message adds a second rule on TH, but the location is now \rfcquote{The
  usual conference room} (see also issue \ref{ADD_Recurrence}). I don't see how these two combined can
  be properly represented in the same event in iCalendar.
  The example says that they are equivalent to the REQUEST given in
  Sec.~4.4.7, but that REQUEST seems to ignore the different
  LOCATION property value of the ADD. I think it should be clarified, how such
  colliding messages should be handled. In particular, do all other
  property values except DTSTART, RDATE and RRULE have to coincide
  with the original REQUEST?
  If not, we should clarify how that case can be handled (i.e. either
  discard all information from the ADD, which does not coincide? Or
  try to merge them as much as possible? Or simply disallow adding
  recurring events to an already recurring event with different
  properties.)

  The same clarification is needed for VTODO (p.47)

  \item Sec.~3.2.5 (p.26): The first sentence talks about sending a
  notice \rfcquote{to the "Attendees"}. To me it is not clear if this means
  sending a CANCEL message to ALL Attendees (even when just
  uninviting one Attendee) or only to the affected (i.e. uninvited)
  Attendees. Both would make sense...

  The same goes for VTODO on p.47.

  \item Sec.~3.2.5 (p.26): In the ATTENDEE comment in the table,
  \rfcquote{from} is missing in \rfcquote{being removed from the event.}

  \item \label{CANCEL_privacy_all_attendees}Sec.~3.2.5 (p.26): Why is it a MUST that all Attendees have
  to be included if the whole event is cancelled? The STATUS property
  already tells the CU(A) whether the whole event was cancelled or
  only some Attendees uninvited. Can't a CUA also send out individual
  CANCEL messages to each of the Attendees with only that one Attendee
  included in the VEVENT? This would prevent privacy issues, because
  sending out the email addresses of all Attendees is not always
  desirable (see also issue \ref{REQUEST_privacy_all_attendees}).

  The same holds for VTODO (p.49)

  \item Sec.~3.2.5 (p.27): The description of STATUS in the table
  is badly worded (Isn't this a contradiction: MUST be set to CANCELLED,
  and MUST NOT be present, if ....).
  I propose to change the first part of the description to
  \begin{verbatim}
     MUST be set to CANCELLED to cancel the entire event.
  \end{verbatim}

  \item Sec.~3.2.6 (p.28): I think DTSTAMP and ORGANIZER also MUST
  be the same value as in the original REQUEST...

  \item \label{REC-ID_VTIMEZONE_required}Sec.~3.2.6 (p.29): Since RECURRENCE-ID is a date-time value,
  it might include a reference to a time zone. In this case, a VTIMEZONE is REQUIRED (instead of the current \rfcquote{0})

  \item Sec.~3.2.7 (p.29, first paragraph): The COUNTER is used not only
  for counter proposals to the event description! I would simply delete
  \rfcquote{description} so the sentence reads \rfcquote{... a counter proposal to
  the event.}

  \item Sec.~3.2.7 (p.30): The SEQUENCE value MUST NOT be changed
  from the original event. I would include this in the comment for
  SEQUENCE (it is mentioned in the examples in Sec.~4.2.4, though).

  \item Sec.~3.2.7 (p.30): In the comment for STATUS, remove the
  space before CANCELLED.

  \item Sec.~3.2.7 (p.31): At the end of this section, it should
  be clarified how the Organizer reacts to the COUNTER. Declining
  it is clear, but if he accepts it, does he have to send out a
  new REQUEST to all Attendees or can he simply do nothing, too?
  In particular, if an Attendee sends a COUNTER with significant
  changes and does not receive a DECLINECOUNTER, can he assume that
  the Organizer has accepted it or does he have to treat it like 
  receiving a DECLINECOUNTER? How does he learn about it other
  than sending a REFRESH?

  \item Sec.~3.2.8 (p.32): VTIMEZONE is required if the RECURRENCE-ID
  contains a reference to a timezone! (like issue \ref{REC-ID_VTIMEZONE_required}).
  
\end{enumerate}

\subsection{Methods for VFREEBUSY Components}
\begin{enumerate}[resume]

  \item Sec.~3.3 (p.32): The third paragraph says that the
  VFREEBUSY MUST include the ATTENDEE in this case, while the
  PUBLISH table in Sec.~3.3.1 expressively forbid this.

  \item Sec.~3.3 (p.33): This section says \rfcquote{However, two
  different busy time periods MAY overlap}, while the restriction
  table in REPLY (sec 3.33, p.36) says that they MUST NOT overlap.

  \item Sec.~3.3 (p.33): Shouldn't it be a SHOULD in \rfcquote{"FREEBUSY"
  properties should be sorted...}?

  \item Sec.~3.3 (p.33): The paragraph starting with \rfcquote{Since
  events may span a day boundary...} is confusing at best. The
  free/busy periods do not necessarily coincide with events, so
  this is no argument. Also, the following sentence sounds a bit
  out of order, since it clarifies the REQUEST method. Instead of
  giving such a lengthy example (talking about "Individuals" not
  supporting busy time requests, while in fact their CUAs don't
  support it), wouldn't it be simpler to reformulate the whole
  paragraph?

  I propose to append
  \begin{verbatim}    Busy time periods may also span a day boundary.\end{verbatim}
  to the previous paragraph and remove the rest of the paragraph,
  since it deals with a fallback and only explains what the methods fallback table in
  Sec.~5.1.2 already says much better.

  \item Sec.~3.3.1 (p.33): Should it really be \rfcquote{...to provide a message for sending unsolicited...} or should it rather be \rfcquote{... to provide a method for sending unsolicited...}?

  \item Sec.~3.3.1 (p.33): Shouldn't it be \rfcquote{The "ORGANIZER"
  property MUST be specified...}?

  \item Sec.~3.3.2 (p.35): The comment for ATTENDEE sounds
  wrong. What is it supposed to mean?

  \item Sec.~3.3.3 (p.36): Remove the parentheses in the
  comment for ATTENDEE and URL.

  \item Sec.~3.3.3 (p.36): Remove \rfcquote{Multiple instances are
  allowed.} in the FREEBUSY comment, since \rfcquote{0+} already says this.

  \item Sec.~3.3.3 (p.36): Why is the sorting a MUST for PUBLISH,
  while the introduction in Sec.~3.3 only speaks of SHOULD?

  \item Sec.~3.3.3 (p.36): Add comment for UID (like for VEVENT):
  \rfcquote{MUST be the UID of the original REQUEST}

\end{enumerate}

\subsection{Methods for VTODO Components}

\begin{enumerate}[resume]

  \item All restriction tables list the PRIORITY property as required for to-dos, while rfc2445bis does not mention any such restriction. I don't think PRIORITY is important enough to warrant a MUST in iTIP.
  \item Sec.~3.4.1 (p.38): Why are Attendees forbidden with PUBLISH?
  \item Sec.~3.4.1 (p.39), Sec.~3.4.2 (p.41), Sec.~3.4.4 (p.47), Sec.~3.4.7 (p.53) and Sec.~3.4.8 (p.55): In the STATUS comment, it should be IN-PROCESS (delete space), similarly it should be NEEDS-ACTION (insert hyphen)
  \item Sec.~3.4.2 (p.39): Only the meaning of REQ-PARTICIPANT is explained. Are other values allowed? If so, what do they mean in connection with to-dos?
  \item Sec.~3.4.2.2 (p.42): If the REQUEST is only used to "reconfirm" the to-do, do the Attendees still have to REPLY, even if nothing has changed? Or should they simply use the value of their RSVP ATTENDEE parameter to decide?
  \item Sec.~3.4.2.3 (p.42): Why can't a to-do be delegated to the Organizer?
  \item Sec.~3.4.2.4 (p.43): Same as \ref{TODO_Forwarding_OrganizerResponse} for VEVENT.
  \item Sec.~3.4.3 (p.44): What exactly is an \rfcquote{unsuccessful "VTODO" calendar component "REQUEST" method}? 
  \item Sec.~3.4.3 (p.43): The same comment about properties that MUST NOT be changed should be inserted as for VEVENT (issue \ref{VEVENT_NotChanged}) on p.23 right before the table.
  \item Sec.~3.4.3 (p.44f): The UID comment should be moved to the ATTENDEE property, which it actually describes, and ATTENDEE should be changed from \rfcquote{1+} to \rfcquote{1} (see also the VEVENT REPLY table on p.23). The new UID comment should be \rfcquote{MUST be the UID of the original REQUEST}
  \item Sec.~3.4.3 (p.45): If the VTODO in the REQUEST contained a VALARM, should this not be included in the REPLY, too?
  \item Sec.~3.4.5 (p.48): \rfcquote{When a VTODO is cancelled} Does this mean only when the whole VTODO (with all its recurrence instances) is cancelled, or does it mean whenever a CANCEL is sent, in particular also when only a single ATTENDEE is unassigned? The same holds for VEVENT (p.26).
  \item Sec.~3.4.5 (p.52): Since the RECURRENCE-ID is a date-time, it can include a reference to a timezone. In this case, a VTIMEZONE is REQUIRED.
  \item Sec.~3.4.7 (p.52): The second sentence of the first paragraph is redundant, since the first sentence already says that the counterproposal is submitted to the Organizer.
  \item Sec.~3.4.7 (p.52): If the counterproposal only contains some minor modifications (e.g. correcting typos in the description), does the Organizer still have to send the REQUEST to all Attendees and set RSVP=TRUE?
  \item Sec.~3.4.7 (p.52): Remove the \rfcquote{;} after "ATTENDEE" property
  \item Sec.~3.4.7 (p.53): In the comment for RECURRENCE-ID remove the spurious \rfcquote{3.5}
  \item Sec.~3.4.8 (p.55): What does the comment for ATTENDEE mean? Does it mean that in a DECLINECOUNTER the Organizer has to insert all original Attendees?

\end{enumerate}

\subsection{Methods for VJOURNAL Components}

\begin{enumerate}[resume]

\item Sec.~3.5.1 (p.57): What is the \rfcquote{original SEQUENCE number} in the comment for SEQUENCE for a PUBLISH of a VTODO? I would delete that first sentence.
\item Sec.~3.5.3 (p.61): VJOURNAL does not allow ATTENDEE, so the presence should be changed to \rfcquote{0} from \rfcquote{0+}.

\end{enumerate}

\subsection{Status Replies}

\begin{enumerate}[resume]

  \item Sec.~3.6 (p.62, item 2. A. and B.) I propose to exchange rules A. and B., delete the last sentence from the current B., and start the current A. with \rfcquote{Otherwise, if any one component}. This makes the logic much clearer.

  \item Sec.~3.6 (p.62ff, column \rfcquote{Offending Data}): The comments in the \rfcquote{Offending Data} column speak about specifying the offending data, but don't make it clear where to specify it. I suppose the idea is to give the offending data in the extdata part of the status message, right? Maybe this could be clarified in a sentence before the table.
  
  \item Sec.~3.6 (p.64, Code 5.0): What does the Return Status Description \rfcquote{Request MAY supported.} mean? (It is grammatically wrong, too.) In particular, the Offending Data column speaks about the METHOD (should be written in all-capitals) property 

\end{enumerate}

\subsection{Implementation Considerations}

\begin{enumerate}[resume]

  \item Sec.~3.7.1 (p.65): In the second paragraph it should be \rfcquote{discrete} instead of \rfcquote{discreet}
  \item Sec.~3.7.1 (p.66): In the last paragraph of this section it should be \rfcquote{or to-do has been made} (instead of \rfcquote{has be made})
  \item Sec.~3.7.1 (p.66): The last three sentences of this section 
  (discussing RECURRENCE-ID) are plain wrong. In particular, they are in
  contradiction to Sec.~3.8.4.4 of rfc2445bis: The RECURRENCE-ID 
  is always the start date of the original recurrence instance, even 
  after the change has been made. As an example, take an event 
  recurring each Monday at 9:00. One of these meetings is moved to 
  12:00 and its LOCATION is changed. Even after the change has been 
  propagated to the Attendees, the RECURRENCE-ID of that event will 
  still be YYYYMMDDT090000, otherwise the recurrence rule would generate an 
  additional event at 09:00 and a RECURRENCE-ID of YYYYMMDDT120000 
  does not appear in the recurrence set either. This is clearly 
  explained in rfc2445bis (Sec.~3.8.4.4, p.116) using the Friday to 
  Thursday change. The RECURRENCE-ID stays on the original date.
  \item Sec.~3.7.3 (p.67): This draft allows clients to completely 
  ignore X-Tokens. Granted, for REPLY, REFRESH etc. there is 
  no advantage in preserving them (because the Attendee's CUA doesn't
  handle them anyway and the Organizer already has their value), but 
  when delegating or forwarding calendar components, the Other CU 
  might be interested in the X-Tokens, because his CUA might know how 
  to handle them.

\end{enumerate}

\section{Examples}
\subsection{Published Event Examples}

\begin{enumerate}[resume]

  \item Sec.~4.1 (p.67): In the first paragraph, change \rfcquote{e- mailing} 
  to \rfcquote{e-mailing} (remove space) and replace \rfcquote{and posting} by 
  \rfcquote{or posting} to make it clearer that this enumeration is not 
  exhaustive and PUBLISH can be used in other ways, too.

\end{enumerate}

\subsection{Group Event Examples}
\begin{enumerate}[resume]

  \item Sec.~4.2 (p.71): In the table change \rfcquote{tentative} to \rfcquote{TENTATIVE}. According to rfc2445bis Sec.~3.1 and 3.2 enumerated property values are case-insensitive, but rfc2445bis and rfc2446bis consistently uses all-capitals for enumerated parameter values.
  \item Sec.~4.2.1 (p.72): The explanation details the default value 
  for PARTSTAT and when it can be left out, but does not mention that 
  the same also holds for CUTYPE=INDIVIDUAL, which could also be left 
  out in the example
  \item Sec.~4.2.1 (p.72): The DTSTART and DTEND coincide. Sec.~3.8.2.2 of rfc2445bis says that the DTEND MUST be later in time than DTSTART! Also, how much sense does a 
  Conference of 0 seconds make?
  \item Sec.~4.2.2 (p.73) and Sec.~4.2.4 (p.76): As explained in issue \ref{DTSTART_Absent} above, 
  rfc2445bis REQUIRES DTSTART to be present in a VEVENT, while the 
  REPLY, REFRESH and DECLINECOUNTER methods defined in this draft forbit
  it. These examples are not valid iCalendar objects as specified by 
  rfc2445bis. The same holds of course for all further REPLY, REFRESH and 
  DECLINECOUNTER examples.
  \item Sec.~4.2.4 (p. 74f): The description says that the given counter-proposal 
  also changes the location, but the LOCATION property value 
  is the same in the REQUEST and the COUNTER.
  \item Sec.~4.2.4 (p.75): The counter-proposal contains the DTSTAMP
  property twice. According to the restrictions table in 
  Sec.~3.2.7 and the VEVENT definition in Sec.~3.6.1 on 
  page 54 of rfc2445bis this is not allowed.
  \item Sec.~4.2.5 (p.76): The second to fourth items of the list 
  should be further indented, since they are actually subitems of 
  the first list item.
  \item Sec.~4.2.5 (p.76): The last item in the list actually 
  contradicts what is said in Sec.~3.2.2.3 (p.20), namely that 
  the delegator MUST add an "ATTENDEE" property describing the 
  Delegate to the REQUEST that he sends to the Delegate. Thus, he 
  definitely MUST NOT send a copy of the original REQUEST, but 
  rather a  slightly modified one.
  \item Sec.~4.2.10 (p.82): In the table replace \rfcquote{Remove an "B" as} by \rfcquote{Remove "B" as}.
  \item Sec.~4.2.10 (p.82): In the table it is not clear to me 
  whether it is a requirement for the Organizer to send the updated 
  event to the remaining Attendees after B was cancelled or not. The
  table describes just one cause of action, but from the definitions
  in Chapter 3, it is also not clear to me whether the Organizer 
  MAY/SHOULD/MUST send a new REQUEST to all remaining Attendees 
  after one Attendee was cancelled.

\end{enumerate}

\subsection{Busy Time Examples}

\begin{enumerate}[resume]

  \item Sec.~4.3 (p.84): Before \rfcquote{Individual A publishes busy time for 
  one week}, a subsection header \rfcquote{4.3.1  Publish Busy Time} should 
  be inserted for consistency (all other METHODS have their own 
  subsection)
  \item Sec.~4.3 (p.85): The description of the example says that 
  busy time for one week was published, but the period specified by 
  DTSTART and DTEND actually is only 6 days! Furthermore, the 
  VFREEBUSY contains FREEBUSY property values that start way beyond 
  the DTEND. rfc2445bis says in Sec.~3.6.4 on p.63 that for published 
  busy time the \rfcquote{DTSTART and DTEND properties specify an inclusive 
  time window that surrounds the busy time information}. In other words,
  all FREEBUSY periods MUST be inside the interval specified by 
  DTSTART and DTEND.

\end{enumerate}

\subsection{Recurring Event and Time Zone Examples}

\begin{enumerate}[resume]

  \item \label{RRULE_INTERVAL} Sec.~4.4.1 (p.87): The description says that this event is 
  for a weekly phone conference, but the RRULE uses INTERVAL=20, which 
  means that the event recurs every 20 weeks! The correct RRULE would be
  \begin{verbatim}
    RRULE:FREQ=WEEKLY;COUNT=20;WKST=SU;BYDAY=TU\end{verbatim}
  I blame this on the ambiguous formulation in rfc2445bis: In 
  Sec.~3.3.10 on p.40 it says \rfcquote{The INTERVAL rule part contains 
  a positive integer representing how often the recurrence rule 
  repeats.} Of course, it is supposed to be interpreted in the 
  sense "in which intervals the r.r. repeats", but can admittedly 
  also be read as "how many times the r.r. repeats". Apparently 
  this was not clear to the person who included this example in 
  rfc2446.
  \item Sec.~4.4.1 (p.88): The paragraph describing the representation of the times in different time zones contains several issues / confusions:
  \begin{enumerate}
    \item The time zone difference for Attendee "b" is expressed as the 
    offset from PDT, while the time zone difference for Attendee 
    "c" is given as the offset from UTC, which makes  comparing 
    these two times much harder. 
    \item In the explicit time listings below, "GMT" is used 
    instead of "UTC". 
    \item JST is 9 hours ahead of UTC, not 8 hours as claimed here.
    \item On November 11, 1997, San Jose is no longer in PDT, but in PST.
    \item On Wed, September 10, 1997, San Jose is still in PDT, not 
    in PST as claimed.
    \item The representation of the exception dates in the other 
    time zones are calculated wrong: 14:00 PDT on Sept 9 is NOT 
    23:00 GMT (=UTC), but rather 23:00 CEST or 21:00 UTC. Similarly, 
    14:00 PST (=UTC-8) on Oct 28 is 22:00 UTC or 23:00 CET or 07:00 
    JST (UTC+9), not 06:00 JST!
  \end{enumerate}
  I would give all times offsets relative to PDT and list the local time zones and all local times mentioned together with their shift from UTC.
  In the list of exceptions, I would also list the PDT/PST date/times 
  first, as they are the real exception dates, the representation in 
  UTC and JST just helps the user to understand the issues with 
  time zones.
  
  All in all, I think that paragraph should be:
  \begin{verbatim}
   The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT 
   (UTC-7). "Attendee" [email-masked] is in France where the local time 
   on this date is 9 hours ahead of PDT or 23:00 CEST (UTC+2). 
   "Attendee" [email-masked] is in Japan where local time is 16 hours 
   ahead of PDT or Wednesday, July 2 at 06:00 JST (UTC+9).  The event 
   repeats weekly on Tuesdays (in PST/PDT). The "RRULE" property results 
   in 20 instances. The last instance falls on Tuesday, November 11, 
   1997 2:00pm PST. The "RDATE" property adds another instance: 
   WED, 10-SEP-1997 2:00 PM PDT.

   There are also two exception dates to the recurrence rule. The first one
   is:

   TUE, 09-SEP-1997 14:00 PDT (UTC-7)
   TUE, 09-SEP-1997 23:00 CEST (UTC+2)
   WED, 10-SEP-1997 06:00 JST (UTC+9)

   and the second is:

   TUE, 28-OCT-1997 14:00 PST (UTC-8)
   TUE, 28-OCT-1997 23:00 CET (UTC+1)
   WED, 29-OCT-1997 07:00 JST (UTC+9)
  \end{verbatim}

  \item \label{ADD_Recurrence} Sec.~4.4.7 (p.93f): It would be very helpful if the comments 
  included an explanation how the added times are added to the original VEVENT. In particular, a single event is added by adding its DTSTART as an RDATE to the original event, possibly with another VEVENT using RECURRENCE-ID to modify some of its properties if the properties of the ADD differed from the original event.
  Similarly, another recurring event can be added by either modifying the existing RRULE or adding a second RRULE (however, rfc2445bis deprecates the use of two RRULEs for a calendar component!). However, it is not clear how one should proceed if the added recurring event differs from the original event (e.g. has a different LOCATION like the second example of this section). As explained in \ref{ADD_Explanation}, the 
  second example adds another recurrence rule to an event with an already
  existing recurrence rule, but the added event has a different LOCATION than the original event. The PUBLISH example, which is claimed to be equal to the REQUEST and the subsequent ADD, however, ignores this changed LOCATION property value and only uses the LOCATION property value of the original event. It should be clarified if changed property values in the ADD should really be ignored or not. If not, this case with an added recurrence needs to be explained further (whether and how it can be represented in iCalendar at all!).
  
  \item Sec.~4.4.9 (p.100): The REPLY contains a REQUEST-STATUS with status code 3.0 and one with code 2.8. However, the previous explanation of REQUEST-STATUS in Sec.~3.6 expressively forbids any non-3.x code if a 3.x code is already present. Thus, the 2.8 code entry should be deleted from the event.

\end{enumerate}

\subsection{Group To-do Examples}

\begin{enumerate}[resume]

  \item Sec.~4.5.1 (p.102): The STATUS property value should be NEEDS-ACTION (Hyphen is missing; enumerated property values are case-insensitive, still I think we should use all-capitals consistently)
 \item Sec.~4.5.6 (p.104): The STATUS property value should be IN-PROCESS rather than the invalid IN-PROGRESS
  \item Sec.~4.5.7 (p.105): Time zones cannot be given as -0700, so I think DTSTART and DUE should be 
    \begin{verbatim}
    DTSTART:19980101T170000Z
    DUE:19980103T170000Z\end{verbatim}
  Additionally, the STATUS property value should be NEEDS-ACTION (hyphen missing)
  \item Sec.~4.5.7.2 (p.105): This section talks about how recurrence works in general for to-dos, which would much better belong in rfc2445bis rather than rfc2446bis. So I think this whole section should be moved to rfc2445bis.
Also, this section speaks of the due date specified in a "REQUEST", while of course the same holds true for PUBLISH, ADD, COUNTER, etc., too. It is not even specific to iTIP, but rather a general issue in iCalendar. The reference to REQUEST should at least be deleted.

\end{enumerate}

\subsection{Journal Examples}

\begin{enumerate}[resume]

 \item Sec.~4.6 (p. 106): The example is missing the REQUIRED DTSTAMP property.

\end{enumerate}

\subsection{Other Examples}

\begin{enumerate}[resume]

  \item Sec.~4.7.1 (p.107): In the describing text the UID value is line-broken, which should not happen.
  \item \label{UID_space} Sec.~4.7.1 (p.107): While rfc2445bis allows spaces in the UID, it's not clear to me whether those spaces are actually part of the UID. In particular, are the following two UID property lines equivalent?
\begin{verbatim}
    UID:[email-masked]
    UID: [email-masked]
\end{verbatim}
  rfc2445bis defines the UID in Sec.~3.8.4.7 to be of text type, which allows spaces, but is quiet on how UIDs should be compared. Reading rfc2445bis strictly, everything after the colon is part of the UID, so that the two lines above are NOT equivalent. The space should proably be deleted from this example, but rfc2445bis should also clarify this case whether spaces are allowed in UIDs and whether leading/trailing spaces should be ignored.

  \item Sec.~4.7.2 (p.107): The second sentence speaks about the case when \rfcquote{an "Organizer" sends a request}, which is an unfortunate wording, because it applies not only to the REQUEST method, but to any iTIP message sent. I would replace \rfcquote{a request} by \rfcquote{an iTIP message}.

  \item Sec.~4.7.2 (p.107): In the explanation for case (1), the case where the SEQUENCE number was incremented by 1 is not a problem and does not mean that the Attendee missed a message or is receiving an out-of-sequence message. Rather is the default case when the Organizer modifies a calendar component: He will increase the SEQUENCE number by 1 and send out a new REQUEST to the Attendees. Thus this case should be not be covered by this case. If the CU receives a REQUEST where the SEQUENCE number is 1 larger than his current version and the RECURRENCE-ID can not be found in his calendar component, that's a worse case, since apparently he received all changes, which do, however, not contain that specific recurrence instance. Only for the CANCEL method the problem arises as described in case (2).

  \item Sec.~4.7.2 (p.108): In the explanation for case (3), I think the Attendee SHOULD/MUST send a response with the status code \rfcquote{2.8; Success, repeating event ignored. Scheduled as a single component}. If he should not send such a reply (since he has probably already sent it when he received the original REQUEST that sets the recurrence), it should be mentioned here explicitly.

  \item Sec.~4.7.2 (p.108): The table and the example cover only case (2), so it should either be moved to the text for (2) or the text above the table should explicitly mention that it covers case (2).

\end{enumerate}

\section{Application Protocol Fallbacks}
\begin{enumerate}[resume]

  \item Between an \rfcquote{Ignore} and some following text in all the tables, the punctuation should be consistent. In some places there is a \rfcquote{,} after the \rfcquote{Ignore}, in some places a period \rfcquote{.} and in some places the text continues after only a space \rfcquote{ }.
  \item Sec.~5.1.1 (p. 110): If a CUA does not support recurrences, it cannot handle ADD by default. There should be a fallback for this case, probably to insert the ADDed event as a separate component and replying with status code \rfcquote{2.8; Success, repeating event ignored. Scheduled as a single component}.

  \item Sec.~5.1.1 (p.110): PRODID and VERSION are REQUIRED for rfc2445bis support, which rfc2446bis relies upon. Still, I agree it does not hurt if a CUA ignores PRODID and/or VERSION, so this can be left unchanged, too. I just wanted to point out that it's already a requirement for rfc2445bis.

  \item Sec.~5.1.1 (p.111), Sec.~5.1.3 (p.113) and Sec.~5.1.4 (p.116): In the ATTENDEE properties, remove \rfcquote{EVENT-}, \rfcquote{VTODO - } and \rfcquote{JOURNAL - }, since there is no method "EVENT-REQUEST" and the fact that this is for events is clear from the section header anyway. If you think it should be left in, it should at least be changed to \rfcquote{REQUEST for events} etc.

  \item Sec.~5.1.1 (p.111) and Sec.~5.1.3 (p.114): In the ATTENDEE properties, change \rfcquote{is not implemented} to the correct \rfcquote{is implemented}.

  \item Sec.~5.1.1 (p.111): In the fallbacks for other calendar methods, there is no requirement to reply with \rfcquote{Not Supported} if the ATTENDEE property is not supported. Why is it a requirement for events?

  \item Sec.~5.1.1 (p.111): Why is DESCRIPTION required? If an event has a SUMMARY, one can safely ignore the DESCRIPTION. On the other hand, many events I have seen have only a SUMMARY (which can be ignored according to the table), but no DESCRIPTION. It would make sense to me to treat SUMMARY and DESCRIPTION similarly.

  \item Sec.~5.1.1 (p.111): I think the ORGANIZER property can only be ignored for PUBLISH, but not for any of the other methods, since that's the address where required replies must be sent to.

  \item Sec.~5.1.1 (p.111): In the fallback for RRULE, change "DTStart" to "DTSTART", since the formatting conventions at the beginning of the draft say that all property names are in capitals.

  \item Sec.~5.1.2 (p.112): Shouldn't there be a fallback for the case where the ATTENDEE property is not supported?
  \item Sec.~5.1.2 (p.112): Why is DURATION support required for VFREEBUSY, when it is not required for VEVENT and VTODO?

  \item Sec.~5.1.3 (p.113) and Sec.~5.1.4 (p.116): RECURRENCE-ID should be changed to \rfcquote{Required if RRULE is implemented}, like it is for VEVENT.

  \item Sec.~5.2.2 (p.117): This section talks only of delegation, but completely ignores that a REQUEST can be forwarded to another CU, who then replies to the Organizer. Additionally, the last sentence poses a possible privacy issue: If the CUA implements the first strategy lined out in the second-to-last sentence (\rfcquote{accept the reply}) and treats the REPLY as a REFRESH, it might automatically send the current version of an event to a person, who is not authorized to have that information.

\end{enumerate}

\section{Security Considerations}
\begin{enumerate}[resume]

  \item Sec.~6.1.5 (p.118): Why is this a "MAY" and not "may"?
  \item Sec.~6.2 (p.118): Remove one of the duplicated \rfcquote{is subject}.
  \item Sec.~6.2.2 (p.119): Procedure alarms were deprecated in rfc2445bis, so the sentence about their security issues can be deleted from rfc2446bis.

\end{enumerate}

\section{IANA Considerations}
No comments.

\section {Acknowledgments}
No comments.

\section{Normative References}
No comments.

\appendix
\section{Appendices}
No comments.

\section*{Issues in rfc2445bis-08}
\addcontentsline{toc}{section}{Issues in rfc2445bis-08}

\setcounter{enumi}{1}
\begin{enumerate}
  \item Sec.~"3.6.1.  Event Component" (p.54): Either make the DTSTART 
  optional in rfc2445bis again or make it REQUIRED in the REPLY, REFRESH and DECLINECOUNTER methods in  rfc2446bis (currently, it MUST NOT be present for these methods).
  \item Sec.~"3.6.5. Time Zone Component" (p.71): The text above the
  example says that this is an example of a time zone using the
  RDATE property. The example, however, does not contain any
  RDATE.

  \item Sec.~"3.8.7.4.  Sequence Number" (p.142): It should be clarified whether the SEQUENCE number
  is supposed to be the same for all different components with the
  same UID (but differing in their use of RECURRENCE-ID to identify
  particular instances of a recurring sequence) or whether they can have different SEQUENCE numbers (see also issue \ref{SEQUENCE_MultipleUID} above).
  
  \item Sec.~"3.3.10.  Recurrence Rule" (p.40): As discussed in issue 
  \ref{RRULE_INTERVAL} for Sec.~4.4 above, the description of 
  INTERVAL can possibly be misunderstood. The next sentence explains 
  it better, but it also only uses an interval of 1. Furthermore,
  anyone who misunderstood the first, ambiguous sentence will not
  be corrected by that second sentence. I propose to change the first
  sentence to: 
  \begin{verbatim}
   The INTERVAL rule part contains a positive integer representing 
   at which intervals the recurrence rule repeats.\end{verbatim}
  Furthermore, I would add one more sentence to that paragraph:
  \begin{verbatim}
   A value of "2" means for example every other day for a DAILY rule, etc.\end{verbatim}
  This explains the use of INTERVAL much better than the default value of "1".

  \item Sec.~"3.8.4.7.  Unique Identifier" (p.120f): As detailled in issue \ref{UID_space} above, it should be clarified how spaces in a UID property value should be handled. In particular, are they allowed at all? Are leading or trailing spaces to be ignored when looking for or comparing UIDs?

\end{enumerate}

\end{document}

--Boundary-00=_7xHxICeqGLWTPkk
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-review

--Boundary-00=_7xHxICeqGLWTPkk--

Date: Thu, 4 Sep 2008 16:09:26 -0400
From: "Anthony Bryan" <[email-masked]>
To: "Julian Reschke" <[email-masked]>
Cc: general discussion of application-layer protocols <[email-masked]>, [email-masked], Applications Review List <[email-masked]>, [email-masked]
Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-02)
Sender: [email-masked]

On Wed, Sep 3, 2008 at 2:54 PM, Julian Reschke <[email-masked]> wrote:
> Anthony Bryan wrote:
>>
>> ...
>>>
>>> One way out of that would by to "grab" special type names like "torrent",
>>> and hardwire them. That should be ok as long as they can't collide with
>>> registered names (thus no "/" allowed).
>>
>> Great, thanks Julian! Thanks to the other people that mentioned this
>> as well, it seems much cleaner & tightened up now. :)
>>
>> Do I need to explicitly state no "/" allowed, or just know any that
>> ones I'm defining can't be "/" ?
>
> I'd say that types without "/" are reserved, and the only reserved value for
> now is "torrent".

Done.

>> And would it be better to just allow the unofficial MIME type, instead
>> of essentially creating an unofficial registry with one or a handful
>> of entries? Or is MIME types plus hardwired entries better?
>> ...
>
> I think you'll see pushback once you start to make normative requirements
> related to unregistered mime types. So, you can also try to get a type
> registered, which of course would be the cleaner solution...

Understood. That would be nice if it already was registered.

I've incorporated these comments into a new draft at
http://tools.ietf.org/html/draft-bryan-metalink-02

There are some issues I would like help from people:

- Inclusion of digital signatures other than PGP.
- Ability to specify if a file is in one or multiple languages.
- Ability to specify if a file is for one or more operating systems.
Maybe using the IANA Operating System Names registry at
http://www.iana.org/assignments/operating-system-names , but these
seem quite outdated. Or possibly using
http://nvd.nist.gov/schema/nvdcve.xsd ?

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
 )) Easier, More Reliable, Self Healing Downloads
_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-review

Date: Tue, 02 Sep 2008 09:46:25 +0100
From: Dave Cridland <[email-masked]>
To: Anthony Bryan <[email-masked]>
Cc: general discussion of application-layer protocols <[email-masked]>, [email-masked], [email-masked], Applications Review List <[email-masked]>
Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01)
Sender: [email-masked]

On Mon Sep  1 06:44:23 2008, Anthony Bryan wrote:
> Here is the Internet Draft for Metalink, available at
> http://tools.ietf.org/html/draft-bryan-metalink-01
> with interim revisions at
> http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ 
> .
> We're looking for review and public comments.

1) I'm not mad keen on namespaces pointing to privately owned domain  
names. You have a different one in the examples as is specified in  
section 1.2, by the way.

2) The type attribute of the hash element ought to have values  
selected from the IANA registry of textual hash names;  
http://www.iana.org/assignments/hash-function-text-names/ - section  
4.1.6.1 & 4.2.4.1.

3) Awesome:

"""
   For convenience, this data format may be referred to as "Metalink
   3.0".  This specification uses "Metalink" internally.
"""

Yeah, so you use a longer, more formal name for *convenience*? And  
then in the specification itself, use a short-hand for, what,  
inconvenience? :-)

4) Notational convention defines a different convention than is used  
in the examples.

5) Section 2, "Metalink Documents MUST be well-formed
   XML." - and presumably "namespace well-formed", as specified in  
[XML-NAMES]? Or not?

6) Section 2: I'd personally kick out xml:base - I don't see it  
solving anything here.

7) Section 4.1.3.1: I'm deeply unconvinced about this "name"  
attribute actually containing a path - I don't see this being needed  
at all. A filename, sure. But otherwise, someone somewhere will  
inadvertantly allow /etc/passwd to be overwritten, or something  
equally hideous. Just ban '/'.

8) Section 4.1.4: "MUST contain one [good] and SHOULD contain more  
than one" - you mean if my download is only available from one  
location then this may provide a cause of poor interoperability? I  
don't think this is what you mean. I think you mean: "MUST contain at  
least one".

9) Section 4.2.3: I'm personally wary of doing this on two grounds.  
Firstly, people invariably use them for advertising, rather than  
debugging. Whilst not all marketing is, in fact, evil, I'm never  
truly keen on adding a bunch of octets for no good reason. Secondly,  
I'd live in perpetual fear that processors will change behaviour  
dependent on the agent's foibles.

10) Section 4.2.13: I had to read this twice to figure out it  
referred to a digital signature of the file to be downloaded. It  
might be as well to define a term for that in section 2, and use it  
throughout. I suspect the nice security people might have something  
to say about specifying PGP-only detatched signatures.

11) Section 4.2.17: Does that "type" attribute totally suck? Of  
course, you have to have it because every man, his dog, and his pet  
hampster has decided that only HTTP is allowed, these days, for  
absolutely everything, leading to a totally useless URI scheme which  
essentially fails to describe the actual resource it's supposedly a  
locator for. Okay, rant over, back to the review.

12) Section 4.2.17.1: Perhaps preference and weight? See SRV.

13) Section 4.2.17.2: Hang on, maybe this is a bit too far - I can  
see the need for type, sure, but I don't see the need to be able to  
specify "Use FTP to retrieve this HTTP URI", because that's just  
introducing a silly state.

14) Section 5 - I'd personally just ditch the entire thing, you  
effectively say all that's needed in Section 8.4.

15) I'm sure a lot of Section 6.1~6.3 could be summed up as "Ignore  
any markup you don't understand, whether from the metalink namespace  
or not." Of course, I'm not really an XML expert, so if this language  
is really needed, that's all fine and good.

Hope this helps, somewhat. Feel free to ignore the bits you disagree  
with.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-review

Date: Wed, 03 Sep 2008 01:05:02 +0100
From: Dave Cridland <[email-masked]>
To: Anthony Bryan <[email-masked]>
Cc: general discussion of application-layer protocols <[email-masked]>, [email-masked], [email-masked], Applications Review List <[email-masked]>
Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01)
Sender: [email-masked]

On Wed Sep  3 00:36:29 2008, Anthony Bryan wrote:
> > 2) The type attribute of the hash element ought to have values  
> selected from
> > the IANA registry of textual hash names;
> > http://www.iana.org/assignments/hash-function-text-names/ -  
> section 4.1.6.1
> > & 4.2.4.1.
> 
> Wow, thank you so much! I didn't know about that. Should I list the
> same hash types, or just have this:
> 
>    The IANA registry named "Hash Function Textual Names" defines  
> values
>    for hash types.
> 
> 
The latter - just point to the registry.

> > 4) Notational convention defines a different convention than is  
> used in the
> > examples.
> 
> The RELAX NG Compact schema doesn't match the rest of the spec? Or
> something else? I'm still working on that, & if anyone wants to help
> out please do because I don't have much experience.
> 
> 
No, your conventions state you'll use a prefix of "metalink", but  
your examples don't. There might have been something else, I forget  
now.

> > 5) Section 2, "Metalink Documents MUST be well-formed
> >  XML." - and presumably "namespace well-formed", as specified in
> > [XML-NAMES]? Or not?
> 
> Yes.
> Is this something I need to add to the draft, or are you mentioning  
> it
> because of internal inconsistencies in the examples?
> 
> 
No inconsistency, I simply thought that might be what you meant.

> > 8) Section 4.1.4: "MUST contain one [good] and SHOULD contain  
> more than one"
> > - you mean if my download is only available from one location  
> then this may
> > provide a cause of poor interoperability? I don't think this is  
> what you
> > mean. I think you mean: "MUST contain at least one".
> 
> Exactly, that was an error.
> 
>       metalink:resources element MUST contain at least one  
> metalink:url
>       element and SHOULD contain more than one metalink:url  
> elements.
> 
> 
No, not what I meant. That "SHOULD" is wrong - it can be a "MAY", but  
"SHOULD" has a particular meaning - it means that if you only list  
one URL here, you risk an interop failure.

RFC 2119 is an addictive drug, but like most strong medicine, best  
used sparingly.

I suspect what you want to write is:

The metalink:resources element MUST contain at least one metalink:url  
element. Typically, such elements contain more than one metalink:url  
element to provide multiple download sources.

> > 10) Section 4.2.13: I had to read this twice to figure out it  
> referred to a
> > digital signature of the file to be downloaded. It might be as  
> well to
> > define a term for that in section 2, and use it throughout. I  
> suspect the
> > nice security people might have something to say about specifying  
> PGP-only
> > detatched signatures.
> 
> Can you suggest wording that is more clear? I've changed it to:
> 
>    The "metalink:signature" element is a Text construct that  
> conveys a
>    digital signature for a file described in a Metalink Document.
> 
> 
Much more obvious.

> I hope some security people will have criticism (& additions) for  
> this
> section. It describes how Metalink functions now, but we don't want  
> to
> be PGP specific. I am not familiar enough with other options to  
> write
> about it :)
> 
> 
I'm sure the security people will chip in.

> Do you suggest removing the "type" attribute & having a new separate
> element as Julian suggested?
> 
> 
Julian knows a lot more about XML than I do, I'd go along with what  
he says.

> > 12) Section 4.2.17.1: Perhaps preference and weight? See SRV.
> 
> I'm not against that if others think that it is necessary/useful,  
> but
> I haven't added it.
> 
> 
Might be worth discussing, at least - I've actually no opinion on the  
subject, I just note that SRV, for one, opted for both, presumably  
based on experience with MX.

> > 14) Section 5 - I'd personally just ditch the entire thing, you  
> effectively
> > say all that's needed in Section 8.4.
> 
> This is taken from the Atom RFC. If it needed to be there, does it
> need to be in this draft as well?
> 
> 
I'm not convinced it needs to be there either.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-review

Date: Wed, 03 Sep 2008 20:54:29 +0200
From: Julian Reschke <[email-masked]>
To: Anthony Bryan <[email-masked]>
Cc: Applications Review List <[email-masked]>, [email-masked], general discussion of application-layer protocols <[email-masked]>, [email-masked], Ian Macfarlane <[email-masked]>
Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01)
Sender: [email-masked]

Anthony Bryan wrote:
> ...
>> One way out of that would by to "grab" special type names like "torrent",
>> and hardwire them. That should be ok as long as they can't collide with
>> registered names (thus no "/" allowed).
> 
> Great, thanks Julian! Thanks to the other people that mentioned this
> as well, it seems much cleaner & tightened up now. :)
> 
> Do I need to explicitly state no "/" allowed, or just know any that
> ones I'm defining can't be "/" ?

I'd say that types without "/" are reserved, and the only reserved value 
for now is "torrent".

> And would it be better to just allow the unofficial MIME type, instead
> of essentially creating an unofficial registry with one or a handful
> of entries? Or is MIME types plus hardwired entries better?
> ...

I think you'll see pushback once you start to make normative 
requirements related to unregistered mime types. So, you can also try to 
get a type registered, which of course would be the cleaner solution...

BR, Julian
_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-review

From: "Brian Smith" <[email-masked]>
To: "'Dave Cridland'" <[email-masked]>, "'Anthony Bryan'" <[email-masked]>
Date: Tue, 2 Sep 2008 16:03:49 -0500
Cc: 'general discussion of application-layer protocols' <[email-masked]>, [email-masked], [email-masked], 'Applications Review List' <[email-masked]>
Subject: [APPS-REVIEW] XML namespace URIs for IETF specifications (was RE: Metalink XML Download Description Format (draft-bryan-metalink-01))
Sender: [email-masked]

Dave Cridland wrote:
> 1) I'm not mad keen on namespaces pointing to privately owned 
> domain names. You have a different one in the examples as is 
> specified in section 1.2, by the way.

What namespace URI namespace should IETF specifications use?
urn:ietf:params:xml:ns:<name>?

http://tools.ietf.org/html/rfc3553
http://tools.ietf.org/html/rfc3688

- Brian

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-review

Date: Wed, 3 Sep 2008 12:01:31 -0400
From: "Anthony Bryan" <[email-masked]>
To: "Julian Reschke" <[email-masked]>
Cc: Applications Review List <[email-masked]>, [email-masked], general discussion of application-layer protocols <[email-masked]>, [email-masked], Ian Macfarlane <[email-masked]>
Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01)
Sender: [email-masked]

On Wed, Sep 3, 2008 at 9:22 AM, Julian Reschke <[email-masked]> wrote:
> Anthony Bryan wrote:
>>>
>>> So, in general, this would be for IRIs that do not identify a resource to
>>> download, but metadata about a resource to download? Strictly speaking,
>>> isn't metalink not yet another format for that?
>>
>> Yes, it is.
>>
>> Do you think about a "metadata" element (a sub-element of
>> "resources")with a required "type" attribute of MIME type is
>> appropriately generic?
>
> Sounds good.
>
>> This could then be used to describe Metalinks if needed, and other
>> types that may come later.
>
> Right.
>
>> I don't think BitTorrent's MIME type is in the is listed in the IANA
>> MIME Media Types. Would this be a problem?
>>
>>   <?xml version="1.0" encoding="UTF-8"?>
>>   <metalink xmlns="http://www.metalinker.org">
>>     <files>
>>       <file name="example.ext">
>>         <resources>
>>           <url>ftp://ftp.example.com/example.ext</url>
>>           <url>http://example.com/example.ext</url>
>>           <metadata
>> type="application/x-bittorrent">http://example.com/example.ext.torrent
>>           </metadata>
>>         </resources>
>>       </file>
>>     </files>
>>   </metalink>
>
> One of these issues that regularly come up :-)
>
> One way out of that would by to "grab" special type names like "torrent",
> and hardwire them. That should be ok as long as they can't collide with
> registered names (thus no "/" allowed).

Great, thanks Julian! Thanks to the other people that mentioned this
as well, it seems much cleaner & tightened up now. :)

Do I need to explicitly state no "/" allowed, or just know any that
ones I'm defining can't be "/" ?
And would it be better to just allow the unofficial MIME type, instead
of essentially creating an unofficial registry with one or a handful
of entries? Or is MIME types plus hardwired entries better?

Here is the changed text:

4.2.9.  The "metalink:metadata" Element

   The "metalink:metadata" element contains the IRI of metadata about a
   resource to download.  For example, this could be the IRI of a
   BitTorrent .torrent file or a Metalink Document.

   metalinkMetadata =
      element metalink:metadata {
         metalinkCommonAttributes,
         attribute preference { xsd:integer }?,
         attribute type { metalinkTextConstruct },
         metalinkUri
      }+

4.2.9.1.  The "preference" Attribute

   metalink:metadata elements MAY have a preference attribute, whose
   value MUST be a number from 1 to 100 for priority, with 100 used
   first and 1 used last.  See the "preference" attribute of the
   metalink:url element for more information.

4.2.9.2.  The "type" Attribute

   metalink:metadata elements MUST have a "type" attribute that
   indicates the MIME type of the metadata available at the IRI.  In the
   case of BitTorrent as specified in [BITTORRENT], the value "torrent"
   is required.

   Metalink Processors that do not support a specified type of metadata
   about a resource to download MUST ignore that metadata

4.2.18.  The "metalink:url" Element

   The "metalink:url" element contains the IRI of a file.  All IRIs MUST
   lead to identical files.

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
 )) Easier, More Reliable, Self Healing Downloads
_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-review