Subject: [ietf-calsify] Editorial issues + Issue 60 [Was: Re: [Ietf-calsify] Re: AD review on 2445bis]

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 20 Oct 2008 12:11:58 -0400

I'm following up on the issues raised by Lisa that were classified as 
Editorial by Aki.  See comments below.

Aki Niemi wrote:
> [CC'd the working group list]
> 
> Hi Lisa,
> 
> Overall, I think these comments fall into two categories; editorial and
> substantial. I've labeled the issues below, and will start a new thread
> on each substantial issue on the list.
> 
> AFAIK, none of the issues you mention have been brought up before. In
> other words, good catches. ;)
> 
> Cheers,
> Aki
> 
> to, 2008-05-29 kello 13:49 -0700, ext Lisa Dusseault kirjoitti:
>> Section references:  Can we break section 3 down for publication?  It  
>> would be so much easier to remember and refer to specific sections of  
>> this document if we had section "4.4." be the UID parameter section  
>> instead of 3.8.4.7.    My eyes just cross at the fourth level of  
>> section nesting.  I am probably abnormally insistent about avoiding  
>> that fourth hierarchy level, and you may all think I'm crazy to  
>> suggest the work and change.  Nevertheless, I'll go ahead and suggest,  
>> without any further pressure, a breakdown and ordering that I,  
>> speaking as an individual and not as an AD (is that enough  
>> disclaimers), would prefer:
>> 	Section 3:   iCalendar Syntax
>> 		Section 3.1: Content lines
>> 		Section 3.2: Value Data Types
>>
>> 	Section 4: ICalendar ojects and Components
>>   		Section 4.1: iCalendar object
>> 		Section 4.2: Components
>>
>> 	Section 5: Properties
>> 		Section 5.1: Property Parameters
>> 		Section 5.2: Calendar Properties
>> 		Section 5.3: Descriptive Component Properties
>> 		Section 5.4: Date and Time Component Properties
>> 		Section 5.5: Time Zone Component Properties
>> 		Section 5.6: Relationship Component Properties
>> 		Section 5.7: Recurrence Component Properties
>> 		Section 5.8: Alarm Component Properties
>> 		Section 5.9: Change Management Component Properties
>> 		Section 5.10: Miscellaneous Component Properties
>>
>> 	Section 6: iCalendar Object examples
>>
>> 	... all further sections ++2
> 
> [editorial]
> 
> I think this change makes sense.

I personally don't see much benefit in doing this change.
No change done.

> 
>> Section -by-section comments:
>>
>> Section 1: This sentence is really out of date/touch:
>> 					However, the longer term growth of
>>     calendaring and scheduling is currently limited by the lack of
>>     Internet standards for the message content types that are central to
>>     these knowledgeware applications.
>>
>> I think we can just drop it unless you think there's something  
>> important to preserve.
> 
> [editorial]

Done.

> 
> I agree.
> 
>> Section 3.2.1:
>> The ALTREP parameter can be used in a lot of places.  I bet it's not  
>> supported everywhere, and some usages of ALTREP could even be  
>> dangerous.  Some health warnings should be added here at least.
> 
> [substantial]
> 
> I think this is also related to another issue listed below on
> strengthening the security considerations section of the draft.
> 
>> Section 3.2.6, DIR parameter:  This should be limited to LDAP URLs  
>> only, if not by requirement then at least by noting that other types  
>> of URLs are likely to be harmful to interoperability.
> 
> [substantial]
> 
>> Section 3.2.10: When a language tag can be used to distinguish between  
>> multiple values, we do need a little guidance about how this is  
>> intended to be used.  How is it used in practice?   Are clients  
>> expected to display only the one that is their most preferred language  
>> among the choices, or are clients expected to display all values and  
>> use the language tag to help display properly?
> 
> [editorial]

This issue has already been raised on the mailing list, see:

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001343.html
http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue60

but never actually addressed in the draft. At some point issue 60 and 35
got mixed up. Going back to the issue tracker I found the following
update from Eliot:

   > msg140 (view)  	Author: lear  	Date: 2006-11-16.14:49:39
   >
   > Consensus to NOT handle multiple LANGUAGE values.
   > Better done in MIME.

As such, I'm proposing the following changes:

--- In RFC2445 section 4.1.2 Multiple Values

Add:

    Multi-valued properties MUST NOT be used to specify multiple language
    variants of the same value. Calendar applications SHOULD display all
    values.

--- In RFC2445 section 4.6.5 Time Zone Component

Change:

    The optional "TZNAME" property is the customary name for the time
    zone. It may be specified multiple times, to allow for specifying
    multiple language variants of the time zone names. This could be used
    for displaying dates.

to:

    The optional "TZNAME" property is the customary name for the time
    zone.  This could be used for displaying dates.

--- In RFC2445 section 4.8.3.2 Time Zone Name

Change:

   Description: This property may be specified in multiple languages; in
   order to provide for different language requirements.

to:

   Description: This property specifies a customary name that can be used
   when displaying dates that occur during the observance defined by the
   time zone sub-component.

--- In RFC2445 section 4.8.3.2 Time Zone Name

Change:

    Example: The following are example of this property:

      TZNAME:EST

    The following is an example of this property when two different
    languages for the time zone name are specified:

      TZNAME;LANGUAGE=en:EST
      TZNAME;LANGUAGE=fr-CA:HNE

to:

    Example: The following are examples of this property:

      TZNAME:EST

      TZNAME;LANGUAGE=fr-CA:HNE

> 
> I suspect this simply needs an implementation note on the subject.
> 
>> Section 3.2.15: RELTYPE.  What does it mean that a calendar component  
>> referenced is the SIBLING of this one?  How is a user agent supposed  
>> to use this information?  Is this parameter ever used except on  
>> RELATED-TO?  Is it actually in use even there?  Health warnings at  
>> least.
> 
> [substantial]
> 
>> Section 3.6.2: VTODO.  Is it now more common for VTODOs to appear in  
>> the same iCalendar document as VEVENTS?  A few years ago that was not  
>> the case.  Can we now state that user agents SHOULD be able to handle  
>> VTODOs as well as VEVENTS?
> 
> [substantial]
> 
>> Section 3.6.3: VJOURNAL: This needs a health warning even more than  
>> VTODO does; some discussion about what users actually do with VJOURNAL  
>> components, if ever, but nevertheless how preserving user data is  
>> important...
> 
> [substantial]
> 
>> Section 3.8.1.10:  Is there some colloquial meaning of "raton- 
>> laveur"?  A naive translation has this as "small rat washer"  and I'm  
>> intrigued by why this would be a required resource for an event...  :)
> 
> [editorial]
> 
> Bernard? 

Raton-laveur is the French name for "raccoon".  It's a pretty dumb
example if you ask me. I'll change the example to:

   RESOURCES;LANGUAGE=fr:Nettoyeur haute pression

Something Lisa has reported to enjoy ;-)

http://nih.blogspot.com/2006/05/i-borrowed-my-neighbours-pressure.html

> 
>> Section 3.8.4.3, 3.8.4.4:   CONTACT and ORGANIZER and RECURRENCE-ID  
>> are defined on VJOURNAL items.  I have no idea what they *mean* on  
>> VJOURNAL.
> 
> [substantial]
> 
>> Section 3.8.8.2:  X- Properties:  We should recommend AGAINST using  
>> these with user-readable strings like
> 
> I think there's some text missing here. Can you clarify?
> 
>> Section 5:  List item 2 is blank. So is #7.
> 
> [editorial]

Fixed.

> 
>> Section 7:  This is probably incomplete.  For example, there are  
>> attacks with embedded HTML that are well-known, and could apply to any  
>> usage of iCalendar.   Have we done brainstorming about other issues?
> 
> [substantial]
> 
>> Section 8:  It would help to add that we are now *updating* IANA  
>> registries that were first established with RFC 2445.  (If we're not  
>> making any changes, it would be good to say that instead).  IANA reads  
>> this section mostly, and depends on this section to figure out what to  
>> do...  Since these registries already exist, we can now put URLs in to  
>> this document to be extra helpful to readers and to the IANA.
> 
> [editorial]
> 
> Good point.

Actually, these registries don't already exist.

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