Subject: Re: SKiCal & QUALVALUE

From: [email-masked]
Date: Fri, 8 Sep 2000 11:49:58 -0400

Pär replied:

>> or probably even:
>>     qualvalparam = "QUALVALUE" =
>>                         ( x-name                ; Experimental type
>>                        / iana-token )          ; Other IANA registered
>>                                                ; type
>
>If you look at the examples:
>ADMISSION;QUALTYPE=SKILL;QUALRULE=RECOMMENDED;QUALVALUE="Horse 
> Riding Experience":
>ADMISSION;QUALTYPE=AGE;QUALRULE=REQUIRED;QUALVALUE=gt 5: 
>you see that the qualvalue can be a range of different types, depending
>on the qualtype.
>So I think we need to allow any 

I do not think that x-name or iana-token restrict the contents of what the 
data can be.  If you check the ABNF from RFC 2445 you will find the 
following relevant snippets:

     iana-token = 1*(ALPHA / DIGIT / "-")
     ; iCalendar identifier registered with IANA
...
     ALPHA      = %x41-5A / %x61-7A   ; A-Z / a-z

     DIGIT      = %x30-39
        ; 0-9

If you check out section 3.2 Parameters of RFC 2445 you can find a useful bit on parameters (the 
optinfo parameter really but it is applicable here):

   The "optinfo" parameter conveys optional information about the
   iCalendar object within the body part. [Snip]
   For example, it can be used to convey the "Attendee" response status
   to a meeting request. The parameter value consists of a string value.

   The parameter can be specified multiple times.
[Snip]
   The value for the "optinfo" parameter is defined as follows:

        optinfo = infovalue / qinfovalue

        infovalue       = iana-token / x-name

        qinfovalue      = DQUOTE (infovalue) DQUOTE

So I do not think that the suggested change to "x-name / iana-token" 
should be any real concern since it allows for any value(s) and it leaves 
the door open for future extensions w/o reissuing the RFCs (as previously 
noted). In rechecking some background I think Ill suggest you recheck the 
part of section 4.1 Content Lines  that talks about how to generally parse property parameters:

     param              = param-name "=" param-value
                          *("," param-value)
        ; Each property defines the specific ABNF for the parameters
        ; allowed on the property. Refer to specific properties for
        ; precise parameter ABNF.

     param-name = iana-token / x-token

     param-value        = paramtext / quoted-string

Perhaps just making the QUALVALUE paramter like the RFC 2445 CN parameter 
is what you want...  2 choices for you to pick from (or you can find 
another).

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Mon, 11 Sep 2000 11:37:29 -0400

Bruce:
I think you mean:
   qualvalparam = "QUALVALUE" "=" text 

or even
   qualvalparam = "QUALVALUE" = text 

-- Frank

---

From: [email-masked]
Date: Mon, 11 Sep 2000 12:14:38 -0400

>   qualvalparam = "QUALVALUE" "=" text 

Correct.  The '=' should have been quoted.

>   qualvalparam = "QUALVALUE" = text 

Nope, thats what I had originally.  In order for the '=' to be part of the 
stream, it must be quoted.

However, if the SKiCal folks are planning on standardizing several 
'examples' then they _really_ should be putting them in the ABNF and 
codifying their proper usage.  Otherwise there will only be a 
tag/parameter but no common values for the tag/parameter; not very useful 
in a standard intended to promote interoperability.

Bruce