Subject: [Ietf-calsify] Re: Chair review of draft-ietf-calsify-rfc2445bis

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 31 Jan 2008 23:29:46 -0500

Hi Aki,

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

Done.

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

Changed with the text provided by Cyrus, that is:

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

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

This issue was discussed during IETF-65.

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

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

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

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

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

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

Done.

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

Done.

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

Done.

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

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

The idnits tool should be fixed to allow this.

Thanks,
Bernard
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify