[Ietf-calsify] SMS alarm

[Arnaud Quillaud]

Probably too late but I thought I'd send this comment anyway...

A *lot* of our customers are using server triggered SMS based alarms 
when currently only:

"AUDIO" / "DISPLAY" / "EMAIL" / iana-token / x-name

are allowed.

I have found only one email related to  SMS based alarms on the calsify 
mailing list 
(http://lists.osafoundation.org/pipermail/ietf-calsify/2006-September/001173.html). 
It simply  suggest the possibility to add more action values.

Now, instead of having to register new actions (and their associated set 
of properties), couldn't we extend the definition of "EMAIL" alarms to 
all forms of electronic messages ? In an EMAIL alarm, the address is 
already stored in an ATTENDEE property so its value can be any RFC3986 
<http://tools.ietf.org/html/rfc3986> compliant URI. This means that in 
theory, we could directly use:

* IM uris (http://tools.ietf.org/html/rfc3860)
* SMS uris (http://tools.ietf.org/html/draft-wilde-sms-uri)

or any other form of electronic message with a known uri definition.

More comments:

Unless I'm mistaken, allowing vendors to register new action values is 
not enough since 
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#section-3.6.6 
limits what you can put in an alarm component:

        alarmc     = "BEGIN" ":" "VALARM" CRLF
                     (audioprop / dispprop / emailprop)
                     "END" ":" "VALARM" CRLF

so maybe the

x-prop / iana-prop

should be removed from audioprop/dispprop/emailprop and added at the 
alarmc definition level, or an otherprop should be added whose 
definition should be part of the iana registry for new actions.

Finally, 
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#section-3.6.6 
mentions that:

<<
It is typically the responsibility of a "Calendar User Agent" (CUA) to deliver the alarm in the specified fashion.
>>

when from my experience, EMAIL is always ignored by CUAs and often 
handled by the CS.

Arnaud Q