Subject: draft-royer-cap-sort-00

From: Harrie Hazewinkel <[email-masked]>
Date: Wed, 18 Jun 2003 14:18:52 +0200

HI Doug,

I read the sorting draft you propose and here are some comment.
Some comments are just text issues, but some are issues I believe
are not resolved or not understood by me.

Harrie
PS: I copied the calsh list, since it is related and useful
if others comment also.

>            CAP (Calendar Access Protocol) sorting extension.
>                         draft-royer-cap-sort-00

> 1. Introduction
>
>    The CALSCH working group decided that sorting would not be in the
>    initial release of CAP.  This memo defines extension to CAP for

defines an extension
(readability)

>    sorting.
>
>    This is an extension to the CAP "GET-CAPABILITY" command result set.

This extension
(Not sure, if the above sentence makes sense here)

>    A CS that supports this extension supplies the "CAP-SORT" property 
> in

'supplies' -> 'MUST supply'
(Use keyword of rfc 2119)

>    its "GET-CAPABILITY" reply supplying the versions of sorting the CS
>    supports.
>
>    If the CUA wishes to have the results sorted it must return to the 
> CS
>    a valid "CAP-SORT" property value.  The CUA can return the 
> "CAP-SORT"
>    value in one of two ways:
>
>    (1) Supply the "CAP-SORT" property as one of the values returned by
>    the CUA in its "GET-CAPABILITY" reply to the CS.  The contents of 
> the
>    "CAP-SORT" sent by the CUA must be from the set supplied to it from
>    the CS "GET-CAPABILITY" command reply "CAP-SORT" property value.
>
>    (2) Supply the "SORT" parameter to a "QUERY" property using one of
>    the values returned in the "CAP-SORT" properly supplied by the CS.

I am not getting this completely. In particular, who (CS or CUA) is
sending what on request and in response of.

>
> 2. MINIMUM-SORT value
>
>    If the CS supplies "MINIMUM-SORT" as one of its values it returns in
>    a "CAP-SORT" property value and the CUA sends "MINIMUM-SORT" as one
>    of its values in a "CAP-SORT" property value or in a "SORT" 
> parameter
>    value then it is defined to cause the CS to perform sorting as
>    defined in this section.

'then it is defined to cause the CS to perform sorting as' ->
'then the CS MUST perform sorting as'

>
>    If supplied as described above to a "QUERY" property, then the query
>    results will be sorted as defined the three sections that follow.

'defined the' -> 'defined in the'

> 2.1 Ordering of Numeric Results
>
>    Sorting will take place in the order the columns are supplied in the

'will take' -> 'MUST take'

>    QUERY command.  The CS MUST sort at least the first column.  The CS
>    MAY sort additional columns.

I can see the order when columns are asked for by specification in the
query, but how about the '*'?? I would also think that it could be
useful to sort on not requested columns.
This part of text applies to section 2.2 also I believe. If so, I would
suggest moving it in section 2.0.

> 2.2 Ordering of Date/Date-Time Results
>
>    Date and date time values will be sorted by their equivalent value 
> in

'will be' -> 'SHOULD be'
(Use the keywords as defined in RFC2119)

>    UTC.  No matter what the returned time zone in the result set
>    returns.  This is so that if multiple components are returned each 
> in
>    a unique time zone, the results will be sorted in UTC.  This does 
> not

'will be' -> 'MUST be'

>    mean the values MUST BE converted to UTC in the data returned to the

'MUST BE' -> 'MUST be'

>    CUA.  It means the CS must do the sort in UTC.

'must' -> 'MUST'

>
>
>    If the cap-cols is only "*" and nothing else and the result set has 
> a
>    DTSTART, then:
>
>    If EXPAND=FALSE sorting will be by the "DTSTART" property value
>    ascending as if it were in UTC.
>
>    If EXPAND=TRUE sorting will be by the "RECURRENCE-ID" property value
>    ascending as if it were in UTC.

"EXPAND" seems to come out of no where.
'EXPAND=..' -> the

>
>    If one or more "DTSTART" or "RECURRENCE-ID" property values in
>    multiple components have exactly the same value, the order for those
>    matching components is unspecified.
>
>    If the selected component(s) do not contain a "DTSTART" property or 
> a
>    "RECURRENCE-ID" property, then the order is unspecified.
>
>    If an instance does not have a "RECURRENCE-ID" property and the 
> query
>    compares "RECURRENCE-ID" properties (comparing a RECURRENCE-ID to 
> the
>    date or date/time of a single instance object), then the CS MUST
>    compare the "DTSTART" property value as if it were a "RECURRENCE-ID"
>    even for single instance objects that do not contain a "RECURRENCE-
>    ID" property.
>
>    A component with a DATE and no TIME value is returned before objects
>    with both a DATE and TIME value when the dates of those two (or 
> more)
>    objects are the same, sorted by date.

I believe that the order within a DATE is unspecified, correct??
I also believe that the above part from "select '*'" is more generic
and applies to the numeric sorting.

>
> 3. LOCALE-SORT value
>
>    If the CS supplies "LOCALE-SORT" as one of its values it returned in
>    a "CAP-SORT" property value and the CUA sends "LOCALE-SORT" as one 
> of
>    its values in a "CAP-SORT" property value or in a "SORT" parameter
>    value then it is defined to cause the CS to perform sorting as
>    defined in this section.
>
>    Values are sorted according to the locale sorting order as specified
>    in the command.  Or the value set by the latest "SET-LOCALE" CAP
>    command, Or the value of the "DEFAULT-LOCALE" property if supplied 
> by
>    the CUA in its "GET-CAPABILITY" reply to the CS.  Or the calendar
>    locale if known.  Or the CS locale if the calendar does not have any
>    locale set.  And the locale to use for the sort is determined in 
> that
>    order.
>
>    If supplied as described above to a "QUERY" property, then the 
> locale
>    to be used in sorting.

Maybe it is my lack of understanding, but I don't get this.

>
> 4. LOCALE parameter
>
>    Parameter Name: LOCALE
>
>    Purpose: To specify the locale to be used.
>
>    Format Definition: The property parameter is defined by the 
> following
>    notation:
>
>
>    ; paramtext is defined in RFC2445
>    ;
>    localeparam    = "LOCALE" "=" paramtext
>
>
>    Description: Defined the locale to be used.

Why repeating the purpose (almost)??

>
>
> 6. CAP-SORT property
>
>    Property Name: CAP-SORT
>
>    Purpose: This property defines the calendar scale used for the
>    calendar information specified in the iCalendar object.

This makes no sense to me. It looks to me an exact copy and paste
from CALSCALE in rfc 2445. Is this intended??

>
>    Value Type: TEXT
>
>    Property Parameters: Non-standard property parameters can be
>    specified on this property.
>
>    Conformance: Property can be specified in an iCalendar object.
>
>    Description:

?? There is none?

>
>    Format Definition: The property is defined by the following 
> notation:
>
>
>    cap-sort      = "CAP-SORT" capsortparam ":" capsortvalue CRLF
>
>    capsortparam  = *(";" xparam)
>
>    capsortvalue  = sorttype *("," sorttype)

How is a sorttype defined?? I cannot find this in rfc 2455.

Another thing that crossed my mind was, what if I sort on STATE??
What would be the order??

ALthough, this approach allows sorting, but I believe the implementation
is way more complex then when added to CAPQL. Just a personal thought,
since the WG has decided SORTING is not part of CAPQL.

Harrie