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

From: Aki Niemi <[email-masked]>
Date: Wed, 19 Dec 2007 16:48:37 +0200

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. 
        
* 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.

* 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)

* 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.
        
* 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.  

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.

* 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.

Nits:
=====

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

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

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 19 Dec 2007 10:25:55 -0500

Hi Aki,

>         Applications MUST ignore x-name and iana-token values that they

I don't like the word "ignore" in this context. It could give an 
implementor the impression that they can simply not store that 
property/value at all, and that would be wrong.

However, you are right in that it is wrong to treat an unknown value as 
TEXT. For example, say I had defined a new value type that was almost like 
TEXT, but did not require the escaping mechanism. Well if a client were to 
treat that as TEXT, and the value contained some characters that would need 
escaping in a TEXT value, then when it wrote out the value it would escape 
the content - that would of course be wrong.

Perhaps a better example would be to consider a client that did not 
understand the RECUR value type - since that value does allow unescaped 
semi-colons, treating it as TEXT would be wrong.

My suggestion for alternative text:

    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.

-- 
Cyrus Daboo

---

From: Aki Niemi <[email-masked]>
Date: Wed, 19 Dec 2007 17:41:57 +0200

>     values that they don't recognize without attempting to interpret or

+1

Cheers,
Aki

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Dec 2007 16:55:26 +0000

Cyrus Daboo wrote:

> Hi Aki,
>
> --On December 19, 2007 4:48:37 PM +0200 Aki Niemi 
> <[email-masked]> wrote:
>
> However, you are right in that it is wrong to treat an unknown value 
> as TEXT. For example, say I had defined a new value type that was 
> almost like TEXT, but did not require the escaping mechanism. Well if 
> a client were to treat that as TEXT, and the value contained some 
> characters that would need escaping in a TEXT value, then when it 
> wrote out the value it would escape the content - that would of course 
> be wrong.
>
> understand the RECUR value type - since that value does allow 
> unescaped semi-colons, treating it as TEXT would be wrong.
>

+1.