Extending CalAddress

[chip]

When a calendar is parsed from a string and turned into a RiCal
object, I find CalAddress to be limited. Despite containing any number
of parameters, a call to an event or freebusy's CalAddress-based
attribute will simply return everything after the first colon it
encounters as it inherits from PropertyValue without any change. This
is quite understandable, as the CAL-ADDRESS definition on page 34 of
RFC2445 is incomplete. There are many examples before and after this
definition in which it is used in conjunction with various property
parameters such as CN, RSVP, ROLE, etc.

As a result, an iCalendar client might generate a string such as

"ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry
Cabot:MAILTO:hca...@host2.com" (p104).

When turned into a RiCal attribute, a call to attendee will simply
return "MAILTO:hca...@host2.com"

Obviously there is a lot of useful information we're missing out on.
Therefore, I've extended the CalAddress object to make creating and
reading attributes from ATTENDEES, OWNERS, ORGANIZERS, etc far easier
and more powerful. I've just implemented RSVP and CN thus far, but
intend to add all of the available property parameters presented in
RFC2445.

My first question: Would this be out of the intended scope of RiCal?

And secondly: I'm having difficulty parsing properties with parameters
as defined in the spec. I have it working fine if I improperly say
ATTENDEES:BLAH=BLA;BLEH=BLE but when I begin the property with a semi-
colon as in

DTSTART;TZID=America/Chicago;VALUE=DATE-TIME:20110906T170000

PropertyValue is stripping out everything past the first colon as
expected (on a CalAddress object). What method do I need to overwrite
to have CalAddress function similarly to DTSTART; or CREATED; in this
regard (the ability to have a property that takes parameters).

I'm sure I'll find the solution sooner or later poking through the
source, but thanks in advance if you happen to know!

One more thing: Why does the spec "mandate" most properties that take
parameters begin with a semicolon, but RRULE only uses a colon
throughout the spec? It seems inconsistent to me, but perhaps there is
something I am missing. Is it because the others eventually take their
property (a date or datetime for DTSTAT or a mailto:[address] for CAL-
ADDRESS) whereas a RRULE is defined by its property parameters alone?