Subject: CAL-QUERY value type

From: Doug Royer <[email-masked]>
Date: Sat, 16 Feb 2002 14:07:46 -0700

Here is the CAL-QUERY value type to be included into CAP.
The CAL-QL section will be submitted separately.

--------------------------------------------------------------------

x.x.1 Property Value Data Types

x.x.1.2 CAP-QUERY Value Type

  To: [email-masked]

  Subject: Registration of text/calendar MIME property value type.

  Value Name: CAP-QUERY

  Value Type Purpose: To define a selection language for identifying
  the contents of iCalendar objects.

  This was based on [SQL92] and [SQLCOM].
  NOTE: This grammar is NOT SQL92.

  (1) All components look like tables for the purpose of
      a QUERY including VALARM. And their contained properties
      looked like columns in those tables.

  (2) All VAGENDAs and CS's look like tables for the purpose of a
      QUERY. And all of their properties look like columns in
      those tables.

  (3) You CAN NOT do any cross component-type joins. And that means
      you can ONLY have one component, OR one VAGENDA OR one CALSTORE
      in the the FROM clause.

  (4) Everything in the SELECT and WHERE clauses MUST be from the
      component type, or VAGENDA OR CALSTORE in the FROM clause.
      This includes the values from the USING_PROPERTIES and
      USING_COMPONENT clauses.

  (5) The '.' means <table>.<column> when needed for contained
      properties or their associated contained components.
      As long as all were contained (as defined by iCalendar or CAP)
      in the SINGLE component type named in the FROM clause OR
      its contained component.

  (6) A contained component without a '.' it is the same as
      <component>.* with the result being a properly formatted
      <component>(s) in the data stream, and correctly formatted
      in the contained component(s) in iCalendar (RFC2445) format.

        VALID:

              (a) SELECT VEVENT.<a-property-name> FROM VEVENT

              (b) SELECT VEVENT.VALARM FROM VEVENT

              (c) SELECT VALARM FROM VEVENT

              (d) SELECT VEVENT.* FROM VEVENT

              (e) SELECT * FROM VEVENT

              (f) SELECT * FROM VEVENT
                   USING_COMPONENTS VALARM alarm
                   WHERE alarm.TRIGGER < '20020201T000000Z'
                   AND alarm.TRIGGER > '20020101T000000Z'

              Note: (a) Selects all instances of <a-property-name>
                    from all VEVENTs.

                    That (b), and (c) yield the same results.
                    And that is select all VALARMS from all VEVENTS.

                    Note that (d) does not enclose them in BEGIN/END
                    VALARM because you selected the properties from the
                    VALARM and not the VALARM.

                    (e) Selects every property and every component
                        that is in any VEVENTs.

                    (f) Selects all properties and all contained
                    components in all VEVENTS that have a VALARM
                    with a TRIGGER property value between the provided
                    dates and times.

        NOT VALID:

              (g) SELECT VEVENT.VALARM.TRIGGER FROM VEVENT

              (h) SELECT DTSTART,UID FROM VEVENT WHERE
                   VTODO.SUMMARY = "Fix typo in CAP"

               Note: (g) Is NOT valid because it contains
                      two '.' characters in the SELECT clause.

                     (h) Is NOT valid because it mixes VEVENT
                     and VTODO properties in the same QUERY.

  (7) When multiple QUERY properties are supplied in a single component
      that contains a QUERY, the results are the same as a logical 'OR'.
      That is all conditions that match any of the QUERY property
      values returned.

    Formal Definition: The value type is defined by the following
    notation:

    comp-name  = "VEVENT"    / "VTODO"   / "VJOURNAL"
               / "VTIMEZONE" / "VALARM"  / "VFREEBUSY"
               / "VAGENDA"   / "VCAR"    / "CALSTORE"
               / "VQUERY"    / iana-name / x-comp

    querycomp  = queries / ( queryname queries) / queryname

    queryname  = "QUERYNAME" *(";" xparam) ":" text CRLF

    queries    = query
               / queries query

    query      = "QUERY" *(";" xparam) ":" capselect CRLF

                 ; NOTE: There is exactly one space separating
                 ; the various parts of capselect
                 ;
    capselect  = "SELECT"   SP   cap-cols  SP
                 "FROM"     SP   comp-name SP
                 *(cauprops SP / capcprops SP)
                 "WHERE"    SP   cap-expr

               / "SELECT" SP cap-cols SP
                 "FROM"   SP comp-name

    capuprops   = "USING_PROPERTIES" SP uprop-list

    uprop-list  = (cap-col SP cap-local)
                / uprop-list SP cap-col SP cap-local

    capcprops   = "USING_COMPONENTS" SP cprop-list

    cprop-list  = (cap-comp cap-local)
                / cprop-list SP cap-col SP cap-local

    cap-col     = ; Any property name found in the component
                  ; named in the comp-tbl used in the FROM clause.
                  ;
                  ;   SELECT ORGANIZER FROM VEVENT ...
                  ;
                  ; OR
                  ;
                  ; A component name of an existing component contained
                  ; inside of the cmp-tbl used in the FROM clause.
                  ;
                  ;   SELECT VALARM FROM VEVENT ...

                  ; NOTE: there is NO space around the "," on
                  ; the next line
    cap-cols    = cap-col / ( cap-cols "," cap-col)
                  / "*"
                  /
    cap-param   = ; Any parameter that may be contained in the cap-col
                  ; in the supplied PARAM() function

    cap-local   = ; Any string that is composed of the characters
                  ; that could be a cap-col name, but is not any
                  ; cap-col name. It is suggested that the
                  ; string start with "x-" to ensure it does not
                  ; conflict with any existing or future cap-col name.
                  ; This name MUST BE defined in the cap-using and
                  ; can only be used in cap-expr of the same query.
                  ; And this name is only known and valid for the
                  ; provided query and only for the lifetime of
                  ; the query. If multiple QUERY properties exist
                  ; in the same component, it is only valid and usable
                  ; in the same QUERY property where it was supplied.

    col-value   = col-literal
                / "SELF()"
                / "CAL-OWNERS(" cal-address ")"
                / "CURRENT-CALID()"

    cal-address = ; A CALID as define by CAP

    col-literal = "'" literal-data "'"

   literal-data = ; Any data that matches the value type of the
                  ; column that is being compared. That is you can
                  ; not compare PRIORITY to "some string" because
                  ; PRIORITY has a value type of integer. If it is
                  ; not preceded by the LIKE element, any '%' and '_'
                  ; characters in the literal data are not treated as
                  ; wildcard characters and do not have to be backslash
                  ; escaped.
                  ;
                  ; OR
                  ;
                  ; If the literal-data is preceded by the LIKE
                  ; element it may also contain the '%' and '_'
                  ; wildcard characters. And if the literal data
                  ; that is comparing contains any '%' or '_'
                  ; characters, they MUST BE backslash escaped as
                  ; described in the notes below in order for them not
                  ; to be treated as wildcard characters.

    cap-ucol    = cap-col / cap-local

    cap-expr    = "(" cap-expr ")"
                / cap-term

    cap-term    = cap-expr SP cap-logical SP cap-expr
                / cap-factor

    cap-factor  = cap-colval SP cap-oper SP col-value
                / cap-colval SP "NOT LIKE" SP col-value
                / cap-colval SP "LIKE" SP col-value
                / cap-colval SP "IS NULL"
                / cap-colval SP "IS NOT NULL"
                / col-value SP "NOT IN" cap-colval"
                / col-value SP "IN" cap-colval"

    cap-colval     = cap-ucol
                / "PARAM(" cap-ucol "," cap-param ")"

    cap-oper    = "="
                / "!="
                / "<"
                / ">"
                / "<="
                / ">="

    cap-logical = "AND" / "OR"

    SP          = ; A single white space ascii character
                  ; (value in HEX %x20).

    CRLF        = ; As defined in RFC 2445.

    xparam      = ; As defined in RFC 2445.

    x-prop      = ; As defined in RFC 2445.

    x-comp      = ; As defined in RFC 2445.

      (1) There is no ORDERBY.  Sorting will take place in the order the
      columns are supplied in the command.

      Float and integer values MUST BE sorted by their numeric value.

      This means the result of a sort on an integer value type will be:

                1, 2, 100, 1000

        and not

                1, 100, 1000, 2

      This means the result of a sort on an float value type will be:

                1.1, 2.23, 100.332, 1000.12

        and not

                1.1, 100.332, 1000.12, 2.23

      Date and date time values will be sorted by their equivalent
      value in 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 mean the values must be converted to UTC in the
      data returned to the CUA. It means the CS must do the sort in UTC.

      All other values are sorted according to the locale sorting order
      as specified in the calendar. Or the CS locale if the calendar
      does not have any locale set, or the host operating system
      locale if the CS does not specify a locale. And the locale to
      use for the sort is determined in that order.

      (2) The CS MUST sort at least the first column.
          The CS MAY sort additional columns.

      (3) If the cap-cols is only "*" and nothing else, then:

            If EXPAND=FALSE sorting will be by the DTSTART value
            ascending.

            If EXPAND=TRUE sorting will be by the RECURRENCE-ID value
            ascending.

          If one or more DTSTART or RECURRENCE-ID components have
          exactly the same value, the order for those matching
          components is unspecified.

      (4) All literal values are surrounded by single quotes ('), not
          double quotes ("), and not without any quotes. If the value
          contains quotes or any other ESCAPED-CHAR, they must be
          backslash escaped as described in section "4.3.11 Text"
          of RFC2445. Any LIKE wildcard characters that are part
          of any literal data that is preceded by a LIKE clause and
          is not intended to mean wildcard search, MUST BE escaped as
          described in note (7) below.

      (5) When comparing DATE-TIME to DATE value types and when
          comparing DATE to DATE-TIME value types, the result will
          be true if the DATE value is on the same day as the DATE-TIME
          value. And they are compared in UTC no matter what time zone
          the data may actual have been stored in.

            VALUE-1             VALUE-2            Compare Results

            20020304            20020304T123456    TRUE
            (in UTC-3)          (in UTC-3)

            20020304            20020304T003456    FALSE
            (in UTC-4)          (in UTC-4)

            20020304T003456Z    20020205T003456    FALSE
            (in UTC-0)          (in UTC-7)

         When comparing DATE and DATE-TIME values with the LIKE
         clause the comparison will be done as if the value is
         a RFC2445 DATE or DATE-TIME string value.

                LIKE '2002%' will match anything in the year 2002.

                LIKE '200201%' will match anything in January 2002.

                LIKE '%T000000' will match anything at midnight.

                LIKE '____01__T%' will match anything for any year or
                                  time that is in January.
                                  (Four '_', '01', two '_' 'T%').

         Again all comparisons will be done in UTC.

         Using a LIKE value of "%00%, would return any value that
         contained two consecutive zeros.

      (6) DTEND and DURATION.

          When a QUERY contains a DTEND value, then the CS MUST also
          evaluate any existing DURATION property value and determine
          if it has an effective end time that matches the QUERY
          supplied  DTEND value or any range of values supplied by
          the QUERY.

          When a QUERY contains a DURATION value, then the CS MUST
          also evaluate any existing DTEND property value and determine
          if it has an effective duration that matches the QUERY
          supplied DURATION value or any range of values supplied by
          the QUERY.

          As DTEND is the first time that is excluded from a components
          time range, any DURATION supplied by the QUERY that is
          exactly one second less than DTEND MUST match the QUERY.
          And if the DURATION ends exactly at the computed DTEND it
          MUST NOT match.

          Any DTEND supplied by the QUERY that is exactly one second
          more than an end time computed from a DURATION MUST match the
          QUERY. Any end time that is computed from a DURATION that
          exactly matches the supplied DTEND MUST NOT match.

            (6.1) Given a meeting room reserved with a component
                  that contains:
                DTSTART:20020127T000000Z
                DTEND:20020127T010000Z

                The reservation is really from:

                        January 27th, 2002 00:00:00
                To:

                        January 27th, 2002,00:59:59

            (6.2) Given another meeting room reserved with a component
                  that contains:

                DTSTART:20020127T000000Z
                DURATION:P59M59S

                The reservation is really from:

                        January 27th, 2002 00:00:00
                 To:

                        January 27th, 2002,00:59:59

            (6.3) A QUERY that contains:

                ... VEVENT.DTSTART = '20020127T00000Z'
                AND VEVENT.DTEND = '20020127T010000Z'

                MUST match both (6.1) and (6.2).

            (6.4) A QUERY that contains:

                ... VEVENT.DTSTART = '20020127T00000Z'
                AND DURATION = 'P59M59S'

                MUST match both (6.1) and (6.2).

      (7) [NOT] LIKE notes:

         The pattern matching characters is the '%' that matches
         zero or more characters, and '_' that matches exactly one
         character (where character does not always mean octet).

         LIKE pattern matches always cover the entire string. To match
         a pattern anywhere within a string, the pattern must start and
         end with a percent sign.

         To match a '%' or '_' in the data and not have it interpreted
         as a wildcard character, they must be backslash escaped.
         That is to search for a '%' or '_' in the string:

               LIKE '%\%%'    Matches any string with a '%' in it.
               LIKE '%\_%'    Matches any string with a '_' in it.

         Strings compared using the LIKE clause MUST BE performed
         using case in-sensitive comparisons. ('a' = 'A').

         If LIKE is preceded by 'NOT' then there is a match when
         the string compare fails.

      (8) 'col-value SP "NOT IN" cap-colval"

          This is similar to the LIKE element, except it does value
          matching and not string comparison matches.

              property:value1,value2
              property:value1,value2
              property:value3

              paramater="1,2,3"

              'value1' IN property   would match
              'value3' IN property   would match
              'value'  IN property   would NOT match
              '2' IN paramater       would match

              LIKE(property, 'value%')       would match
              LIKE(paramater, '2%')          would match

          The CS must understand the objects being compared and
          understand how to determine how any multi valued or multi
          instances properties or parameter values are separated,
          quoted, and backslash escaped and perform the comparisons as
          if each value existed by itself and not quoted or backslash
          escaped when comparing using the CONTAINS() element.

          If IN is preceded by 'NOT' then there is a match when
          the value does not exist in the property or parameter value.

        (9) DATE-TIME and TIME values in a WHEN clause.

            All DATE-TIME and TIME literal values supplied as in
            a WHEN clause MUST BE terminated with 'Z'. That means
            that the CUA MUST supply the values in UTC.

            Valid:

                  WHERE alarm.TRIGGER < '20020201T000000Z'
                   AND alarm.TRIGGER > '20020101T000000Z'

            Not valid:

                  WHERE alarm.TRIGGER < '20020201T000000'
                   AND alarm.TRIGGER > '20020101T000000'

            It is a syntax error and the CS MUST reject the QUERY.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 21 Feb 2002 12:06:54 -0500

> The CAL-QL section will be submitted separately.

Subject: Registration of text/calendar MIME value type CAP-QUERY

>   the contents of iCalendar objects.

That's the purpose of this section, not of the value type
per say.  Based on the description of other "value type
purposes", I think it would be more appropriate to write
the following:

  This value type is used to identify values that contain
  query statements targeted to a calendar store (CS).

The following information does not belong in the registration
of the value type CAL-QUERY.  This section should focus on the
syntax only.  The semantic should be defined elsewhere in the
draft.

>       QUERY. And all of their properties look like columns in

As VAGENDA, VCALSTORE, and VALARM are all components, how about
merging (1) and (2) together and simply state the following:

(1) For the purpose of a query, all components should be
    handled as SQL tables, and the properties of these
    components, should be handled as SQL columns.

>       you can ONLY have one component, OR one VAGENDA OR one CALSTORE

We should rephrase this paragraph to avoid using
"You" in the draft.  Also, "CAN NOT", "ONLY" and
"OR" are not defined in RFC 2119.

Furthermore, change CALSTORE to VCALSTORE
(as well as everywhere else in the text).

>       This includes the values from the USING_PROPERTIES and

We should rephrase this paragraph.  Perhaps splitting
it in two paragraphs would help (for SELECT and WHERE).
(It's USING_COMPONENTS with an 'S').

>       in the SINGLE component type named in the FROM clause OR

This paragraph will be hard to understand for the
first time readers.  Perhaps we could rephrase it?

>       in the contained component(s) in iCalendar (RFC2445) format.

We should clarify what is "a contained component".

This paragraph should specify to which part of
CAL-QUERY it applies (SELECT clause only?).

>               (a) SELECT VEVENT.<a-property-name> FROM VEVENT

This is not valid according to the rule part cal-col
of the ABNF specified below (per the calendar store
model a VEVENT cannot contain another VEVENT).

Perhaps we could change this example to:

   (a) SELECT VEVENT.<a-property-name> FROM VAGENDA

>               (b) SELECT VEVENT.VALARM FROM VEVENT

Same problem as (a).  How about:

   (b) SELECT VEVENT.VALARM FROM VAGENDA

>               (d) SELECT VEVENT.* FROM VEVENT

Same problem as (a), and this is not valid according to
the rule part 'cal-cols' of the ABNF specified below.

>                     And that is select all VALARMS from all VEVENTS.

Change VALARMS to VALARMs, or even better: "VALARM components".
Same for VEVENTS.

>                     VALARM and not the VALARM.

Sorry, I don't understand this paragraph at all.

>                     (e) Selects every property and every component

If (d) was valid, what would be the difference between
(d) and (e)?

>                       two '.' characters in the SELECT clause.

It's not valid because a VEVENT cannot contain VEVENT.
Change to:

   SELECT VEVENT.VALARM.TRIGGER FROM VAGENDA

But then, I don't see any problem allowing more than
one '.' character in the SELECT clause.

>                      and VTODO properties in the same QUERY.

(h) is not valid because of the limitation specified in (4).
Not because it mixes VEVENT and VTODO "properties (?)".

>       That is all conditions that match any of the QUERY property

This needs to be rephrase.  How about:

(7) When multiple QUERY properties are supplied in a single VQUERY
    component, the results returned are the same as the results
    returned for multipled VQUERY components having each a single
    QUERY property.

>                  ; the various parts of capselect

These rule parts don't belong in this section.  We need separate
sections to register these.  That is,

   Subject: Registration of text/calendar MIME component VQUERY

   Subject: Registration of text/calendar MIME property QUERYNAME

   Subject: Registration of text/calendar MIME property QUERY

>                  *(cauprops SP / capcprops SP)

Typo:

*( capuprops SP / capcprops SP )
     ^

>                / "SELECT" SP cap-cols SP

For the sake of simplicity we should rename "capselect"
to "cal-query" to match the name of the value type.
That will make referencing to this value type easier.

>     cprop-list  = (cap-comp cap-local)

Add missing SP rule part:

(cap-comp SP cap-local)
          ^^

>                   ; NOTE: there is NO space around the "," on

We can't define a rule part only with comments.

>     cap-cols    = cap-col / ( cap-cols "," cap-col)

Remove trailing '/'.

>                   ; in the supplied PARAM() function

Define.

>                   ; in the same QUERY property where it was supplied.

As was discussed on the list, there is no "conflict" here.
http://www.imc.org/ietf-calendar/mail-archive/msg03622.html

On the other hand, I totally agree that a bad choice of
variable names can bring "confusion".

In any case, prefixing variables with "my" (e.g., "myAlarm")
should be sufficient to avoid any confusion (beside, the odds
of having to deal with a property called "x-alarm" is probably
higher than "myAlarm").

>     cal-address = ; A CALID as define by CAP

Define.

>       This means the result of a sort on an integer value type will be:

Add missing 'Z' (i.e., LIKE '%T000000Z').  See (9) below.

>                LIKE '%\_%'    Matches any string with a '_' in it.

We should add another example to show how to match '\':

                 LIKE '%\\%'    Matches any string with a '\' in it.

>           matching and not string comparison matches.

We should use a specific property in our example, since
the comma (",") is not defined as a value delimitor for
all properties (e.g., SUMMARY:Hello, world!).

>               paramater="1,2,3"

Should probably be:

   parameter=1,2,3

else, '2' IN parameter would NOT match.

(parameter is spelled paramAter in many places here)

Again, use a specific parameter for which the
comma is defined as a value delimiter.

>               LIKE(paramater, '2%')          would match

LIKE(parameter, '2%')  would NOT match
since the value doesn't start with '2'.

>           escaped when comparing using the CONTAINS() element.

CONTAINS() no longer exists.

>         (9) DATE-TIME and TIME values in a WHEN clause.

There is no WHEN clause.

>             It is a syntax error and the CS MUST reject the QUERY.

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Feb 2002 10:45:24 -0700

>   query statements targeted to a calendar store (CS).

For the most part - yes. But it is a general 2445 property
value type we are registering. So, I'll replace "calendar
store (cs)" with something generic.

One of the goals we had in 2445 was that we tried not
to define which draft or objects the properties were
used in so that we could re-use them at a later time
and not have to retrofit an existing RFC.

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Feb 2002 10:49:48 -0700

> syntax only.  The semantic should be defined elsewhere in the

Did you mean only the next two lines?

> >   NOTE: This grammar is NOT SQL92.

If so, then I disagree. Knowing that it is SQL like is
very important.

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Feb 2002 10:52:51 -0700

>     components, should be handled as SQL columns.

I think there will be an objection to using phrase 'SQL'.
Which is why the note I about 'like' SQL needs to stay.

I agree - otherwise:

 (1) For the purpose of a query, all components should be
     handled as tables, and the properties of these
     components, should be handled as columns.

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Feb 2002 10:58:00 -0700

> (as well as everywhere else in the text).

Yes - some of the text was written before the proposal
to change it from CALSTORE to VCALSTORE.
These I think fall into clean up work and we do have
a lot of cleanup to do.

There was some email - and I don't think that anyone
has a problem with this.

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Feb 2002 10:59:48 -0700

Bernard Desruisseaux wrote:

> >       USING_COMPONENTS clauses.
> 

Can do - agreed.

---

From: Alan Davies <[email-masked]>
Date: Thu, 21 Feb 2002 13:09:54 -0500

>      components, should be handled as columns.

sub-components can also be used as columns though, so the
analogy might not be useful (or perhaps should be expanded
a little), e.g. :

SELECT VALARM FROM VEVENT where [...]

--Alan

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Feb 2002 11:12:32 -0700

> We should clarify what is "a contained component".

I'll a definitions in the definitions section, like:

     "contained component" - A component that is contained
     inside of another component. VALARM for example may be
     contained inside of a VEVENT.

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Feb 2002 11:09:15 -0700

> first time readers.  Perhaps we could rephrase it?

Yes.

How about:

	(5) The '.' is used to separate the table name (component)
            and column name (property) when selecting a property that
            is contained inside of a component that is targeted in
            the TARGET property.

	    In this example the '.' is used to separate the
            TRIGGER property from its contained component (VALARM)
	    which is contained in any VEVENT in the selected TARGET
            (relcalid). All TRIGGER values in any VEVENT in relcalid
            would be returned.

		TARGET:relcalid
		QUERY: SELECT VALARM.TRIGGER FROM VEVENT

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Feb 2002 11:18:29 -0700

> model a VEVENT cannot contain another VEVENT).

It should say (as the text below in the original post states
it selects ALL properties with that name from all VEVENTs):

       SELECT <a-property-name> FROM VEVENT

> Same problem as (a).  How about:

It should say (similar - it was intended to say how to
get all VALARMs from all VEVENTs):

	SELECT VALARM FROM VEVENT

> the rule part 'cal-cols' of the ABNF specified below.

It should say:

	SELECT * FROM VEVENT 

And (e) should be dropped.

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Feb 2002 11:23:44 -0700

> Sorry, I don't understand this paragraph at all.

:-) It must be one of those read my mind statements.

Change the last VALARM to VEVENT.

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Feb 2002 11:21:09 -0700

Yes.

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Feb 2002 11:26:21 -0700

Yes.

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Feb 2002 11:30:23 -0700

>    Subject: Registration of text/calendar MIME component VQUERY

Yes - and I don't see that I defined VQUERY here.

>    Subject: Registration of text/calendar MIME property QUERYNAME

Yes - and I thought we were going to call id QUERYID and
and an optional NAME to VQUERY?

Yes.

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Feb 2002 11:49:20 -0700

> That will make referencing to this value type easier.

yes.

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Feb 2002 11:51:53 -0700

> of having to deal with a property called "x-alarm" is probably

I'll change it to:

	"my-" 

Agree?

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Feb 2002 12:53:24 -0700

> all properties (e.g., SUMMARY:Hello, world!).

I'll change the example to be a mixture of possible iCalendar
multiple instance and multiple valued properties and parameters
and I add this text before the example:

Some iCalendar objects can be multi instance and multi valued.
The IN operator will return a match if the literal value supplied as
part of the 'IN' clause is contained in the value of any instance
of the named property or parameter, or is in any of the multiple
values in the named property or parameter.

	BEGIN:A-COMPONENT
a	property:value1,value2		One property, two values.
b	property:"value1,value2"	One property, one value.
c	FOO:paramater=1,2:x		One parameter, two values.
d	FOO:paramater="1,2",3:y		One parameter, two value.
	END:A-COMPONENT

	'value1' IN property		would match (a) only.
	'value1,value2' IN property	would match (b) only.
	'value%'  IN property		would NOT match any.
	'2' IN parameter		would match (c) only.
	'1,2' IN parameter		would match (d) only.

	LIKE(property, "value1%"	would match (a) and (b)
	LIKE(property, 'value%')	would match (a) and (b)
	LIKE(paramater, '1%')		would match (c) and (d)
	LIKE(paramater, '%2%')		would match (c) and (d)

And I'll add this text to the start of the paragraph
that follows the example:

  Some property values (such as the 'recur' value type), contain
  commas and are not multi valued. The CS must understand the objects
  being compared and ...