Re: iCal-06 and "property-specific parameters"

[Bruce_Kahn@xxxxxxxx]

Daryl wrote:
>I believe the concept of property specific parameters should be removed
>from the iCAL spec and all the current property specific parameters be
>promoted to actual property parameters.

Before we try this, could you please tell us what the meaning of a SENT-BY
would be on the UID, RECURRENCE-ID, or other property (besides ATTENDEE and
ORGANIZER) would be?  How about RANGE for any other property except
RECURRENCE-ID?

These specific property parameters only have any real meaning on those they
are applied to in the draft.  By allowing them on properties where they do
not make sense you could say that it makes the text a bit simpler (but not
much Ill claim).  However, it would legitimize non-sensical entries like:

UID; RANGE=THISANDFUTURE; SENT-BY=Clueless@foo.org: 1234567890@foo.org
ATTENDEE; RELTYPE=PARENT; STATUS=ACCEPTED; TYPE=Individual:
FDawson@earthlink.net

The text of 4.2 you cited basically allows a property to define a property
parameter that is specific to it and not ALL the other properties at large.
This is a good thing as why allow all property parameters on all properties
when they do not make sens??

>Why is it a good thing to have property specific parameters, some of which
>are actually duplicated in different component properties (CN, DIR,
>SENT-BY)? [Snip]
>   Each of the Time Zone Component Properties
>(with the already noted exception of TZID) have a statement to the effect
>of:
>
>    This property MUST only be specified in a "VTIMEZONE" calendar
component.
>
>If this is the case, then why don't we extend the property specific
>parameters to component specific parameters [Snip]

You noted CN, DIR and SENT-BY as being shared but this is not a problem.
Their functions are 'shared' between ATTENDEE and ORGANIZER due to the role
changes that were added recently.  This is bound to happen when some
properties share similar needs or functions.  No biggie in the grand scheme
of the size of iCalendar.

Besides, by 'extending' this down to the property parameter level you would
in effect have to redo LOTS of text, add new blocks for the formerly
prorperty specific parameters and then add all kinds of ABNF changes.  This
is too much to ask given the stage in the process we are at; especially
since there is no real technical reason or need for it.  As is now, any
property parameter that applies to all properties sensibliy is decribed
separately to avoid bloating of the text.  Any property specific parameters
are rightfully described on only those properties that they belong to.
Sounds like a sensible approach to me.

Bruce
===========================================================================
Bruce Kahn                                    INet: Bruce_Kahn@iris.com
Standard disclaimers apply, even where prohibited by law...