Useful links:

• RFC6321, xCal: The XML Format for iCalendar.

To-do:

• [x] require sabre/xml,
  • [x] update composer.json,
  • [x] sabre/xml requires PHP5.4, hence update sabre/vobject (done by Composer?),
    • [x] if requires PHP5.4, we can use the JsonSerializable everywhere (all top-classes having a jsonSerialize method),
    • [x] update code accordingly (e.g. short array syntax),
    • [ ] update documentation accordingly,
• [x] create the helper in Sabre\VObject\Reader,
• [x] add XML serializer helpers everywhere (e.g. in children of Sabre\VObject\Node),
• [x] timezones used by xCal and xCard are differents, must check the compatibility,
• [x] create the reader (parser):
  • [x] support properties:
    • [x] support all names,
    • [x] support all values (types of values):
      • [x] binary,
      • [x] boolean,
      • [x] cal-address,
      • [x] date,
      • [x] date-time,
      • [x] duration,
      • [x] float,
      • [x] integer,
      • [x] period,
        • [x] start,
        • [x] duration,
        • [x] end,
      • [x] recur,
        • [x] until,
        • [x] count,
        • [x] interval,
        • [x] bysecond,
        • [x] byminute,
        • [x] byhour,
        • [x] byday,
        • [x] bymonthday,
        • [x] byday,
        • [x] byyearday,
        • [x] byweekno,
        • [x] bymonth,
        • [x] bysetpos,
        • [x] wkst,
        • [x] freq,
      • [x] text,
      • [x] time,
      • [x] uri,
      • [x] utc-offset,
    • [x] support special cases:
      • [x] categories,
      • [x] resources,
      • [x] freebusy,
      • [x] exdate,
      • [x] rdate,
      • [x] geo,
        • [x] latitude,
        • [x] longitude,
      • [x] request-status,
        • [x] code,
        • [x] description,
    • [x] support all parameters:
      • [x] support the specific value iCalendar parameter,
  • [x] support all components:
    • [x] vevent,
    • [x] vtodo,
    • [x] vjournal,
    • [x] vfreebusy,
    • [x] vtimezone,
    • [x] standard,
    • [x] daylight,
    • [x] valarm,
  • [x] support XML extensions.

Code review:

• usage of iterators has been heighten (see https://github.com/fruux/sabre-vobject/pull/161),
• clean code (https://github.com/fruux/sabre-vobject/pull/162),
• better performance when possible (see https://github.com/fruux/sabre-vobject/pull/162).

Left apart for now:

• [x] RFC6321, section 3.1. Pre-Processing,
• [x] LIBXML_* options when reading or writing.

To fix:

• [x] rdate.

A property which requires comma or semi-colon escaping isn't being handled by the proerty serializer. For example:

$entry->description = 'this; and, then that';

gets pumped out as:

DESCRIPTION: this; and, then that

When it should be:

DESCRIPTION: this\; and\, then that

To add to the problem, I can't manually escape my text, as that just results in my user generated backslashes being escaped:

$entry->description = addcslashes('this; and, then that', ',;');

DESCRIPTION: this\\; and\\, then that

To fix the problem, I changed the property serializer to use the same escape parameters as the parameter serializer (Property.php around line 176):

$src = array(
            '\\',
            "\n",
            ';',
            ',',
        );
        $out = array(
            '\\\\',
            '\n',
            '\;',
            '\,',
        );
        $str.=':' . str_replace($src, $out, $this->value);

That does it, but I'm not comfortable enough with the RCF to know if this has side effects when serializing other parameters.

Given the following VEVENT:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//RoundCube CalDAV Client//EN
BEGIN:VEVENT
CREATED:20110305T003637Z
LAST-MODIFIED:20110305T003705Z
DTSTAMP:20110305T003705Z
UID:910fa9d0-b2a0-4c91-94f9-ccc088be7cae
SUMMARY:My birthsday
CATEGORIES:Birthday
TRANSP:TRANSPARENT
LOCATION:
DESCRIPTION:
DTSTART;VALUE=DATE:20140307
DURATION:P1D
RECURRENCE-ID;VALUE=DATE:20140307
END:VEVENT
END:VCALENDAR

Which is the result of the following calendar-query to a CalDAV server:

<?xml version="1.0" encoding="utf-8" ?>
<C:calendar-query xmlns:D="DAV:"
                  xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:prop>
    <C:calendar-data>
    <C:expand start="20140101T000000Z"
                       end="20140401T000000Z"/>
    </C:calendar-data>
    <D:getetag/>
  </D:prop>
  <C:filter>
    <C:comp-filter name="VCALENDAR">
      <C:comp-filter name="VEVENT">
        <C:time-range start="20140101T000000Z"
                             end="20140401T000000Z"/>
      </C:comp-filter>
    </C:comp-filter>
  </C:filter>
</C:calendar-query>

In the above query we are requesting the CalDAV server to expand recurring events to the given time-range which is a perfectly normal ting to do.

Calling the method 'getBaseComponents' will return an empty array due to this statement: if (isset($component->{'RECURRENCE-ID'})) continue;

If the above statement is commented out everything works as expected.

When the RRule FREQ is YEARLY and it uses BYYEARDAY only, an infinite loop could occur. $this->currentDate may be an DateTimeImmutable, so a reassignment is necessary.

I have a UTF-8 vcf-file which vobject appears unable to handle. vobject will flat out not recognize the file. The problem appears to be the Initial Byte Order Mark. http://en.wikipedia.org/wiki/Byte_order_mark. Removing the BOM enables vobject to parse the file.

Seeing how I found an android utility which created this file, this is a real-world example.

I have not found anything expressively prohibiting the use of a BOM in rfc 6350, but I'll admit to neither being a skilled reader of RFCs, nor a programmer. In any case, it does not appear to be a very hard thing to fix?

As the current date is immutable every modification needs a reassignment. If you use the following rrule, then the wile loop never ends because we always test with the same date and not the modified one. RRule to test:

FREQ=YEARLY;COUNT=7;WKST=MO;BYDAY=MO;BYWEEKNO=13,15,50

Discovered on Sabre/VObject 3.5.0 reproducible on Sabre/VObject 4.1.0

PHP script to reproduce error:

<?php

include 'vendor/autoload.php';

$data1 = "BEGIN:VCARD\r\nVERSION:3.0\r\nPRODID:-//Sabre//Sabre VObject 3.5.0//EN\r\nUID:12345\r\nFN:12345\r\nN:12345;;;;\r\nPHOTO;TYPE=JPEG:http://example.org/photo.jpg\r\nEND:VCARD\r\n";
$data2 = "BEGIN:VCARD\r\nVERSION:4.0\r\nPRODID:-//Sabre//Sabre VObject 3.5.0//EN\r\nUID:12345\r\nFN:12345\r\nN:12345;;;;\r\nPHOTO:data:image/jpeg;MTIzNDU=\r\nEND:VCARD\r\n";

$v1 = \Sabre\VObject\Reader::read($data1);
$v2 = \Sabre\VObject\Reader::read($data2);

echo "V1: " . $v1->PHOTO->getValueType();
echo "\n-----------------\n";
echo "V2: " . $v2->PHOTO->getValueType();

results in ...

V1: BINARY
-----------------
V2: URI

expected ...

V1: URI
-----------------
V2: BINARY

Is there an easy way to pull back multiple types for tel?

Something like this, only pulls back the first:

foreach($this->_vcard->TEL as $tel) { echo $tel['TYPE'] . ' : ' . $tel . "\n"; }

If I var dump the object $tel, I can see them in parameters?

Thanks Tom

Ical content from some event providers do contain white spaces after some properties like the DTSTAMP field. This is not valid ical content, but can be easily solved by trimming white spaces from the value of the property. It makes VObject more robust.

Hi,

parsing an iCalendar file then serialising it gives me a diff. Among other things, double-quotes are now prefixed with a backslash because the incoming “"” is handled as backslash plus double-quote, instead of escaped double-quote (which is what KDE Kontact wrote):

-DESCRIPTION:innerer•text\ngeht yber\n\nmehrere•zeilen\n\nab dem 
- 10.09. 6x jede woche bis auf 17.09. also noch 24.09. und 01.10. und 
- 08.10. und 15.10.\n\nescaping: ' \" \\ \; \, : & < > !\n\nund mit 
- modifikation.
+DESCRIPTION:innerer•text\ngeht yber\n\nmehrere•zeilen\n\nab dem 10.09. 
+ 6x jede woche bis auf 17.09. also noch 24.09. und 01.10. und 08.10. und 15
+ .10.\n\nescaping: ' \\" \\ \; \, : & < > !\n\nund mit modifikation.

Now that we finally have a Property::getValue() (hooray) that returns the value in a datatype native to PHP without all the base64/quoted-printable encoding fuzz, I think it should also support (de)encoding according to its CHARSET parameter. Specifically MS outlook (and very likely others) usually uses the native system encoding and includes this in the CHARSET declaration only once special characters (outside of the standard ASCII range?) are included in the property value.

Now that VObject v3 is right around the corner, I'd vote for including it before the feature freeze to avoid breaking the API once again.

I'll see if I can contribute some patches, but I wanted to post this right away.

This PR fixes two issues encountered on a V4 VCard.

1. RFC6350 allows escaping of semicolons in property values, but vobject did not unescape them in input. data URIs used for inline images in v4 VCard contain both semicolon and comma. When the semicolon is escaped (which is optional for the producer of the VCard), it must be unescaped by the consumer or the resulting URI will still contain the backslash and be malformed.
2. Mime types are case insensitive (RFC2045). In the vcard converter in conversion from v4, the mime type is checked in a case sensitive manner and would thus fail to convert the mime type if it is not lowercase in the input. Changed the handling to treat this case-insensitive.

Tests adapted / extended accordingly.

Hello,

For the AntennaPod project we're dynamically generating an ics file based on the events created on our website (https://github.com/AntennaPod/antennapod.github.io/pull/192). The ics file contains the following line: RDATE;VALUE=PERIOD;TZID=Europe/Brussels:20221022T160000/20221022T170000.

When adding this to my Nextcloud calendar app as read-only calendar ('new subscription via link'), I get an error and the log shows this:

[webdav] Fout: Sabre\VObject\InvalidDataException: The supplied iCalendar datetime value is incorrect: 20221022T160000/20221022T170000 at <<closure>>

 0. /var/www/html/3rdparty/sabre/vobject/lib/DateTimeParser.php line 205
    Sabre\VObject\DateTimeParser::parseDateTime("20221022T160000/20221022T170000", DateTimeZone {})
 1. /var/www/html/3rdparty/sabre/vobject/lib/Recur/RDateIterator.php line 99
    Sabre\VObject\DateTimeParser::parse("20221022T160000/20221022T170000", DateTimeZone {})
 2. /var/www/html/3rdparty/sabre/vobject/lib/Recur/EventIterator.php line 362
    Sabre\VObject\Recur\RDateIterator->next()
 3. /var/www/html/3rdparty/sabre/vobject/lib/Recur/EventIterator.php line 335
    Sabre\VObject\Recur\EventIterator->next()
 4. /var/www/html/3rdparty/sabre/vobject/lib/Recur/EventIterator.php line 190
    Sabre\VObject\Recur\EventIterator->rewind()
 5. /var/www/html/apps/dav/lib/CalDAV/CalDavBackend.php line 2763
    Sabre\VObject\Recur\EventIterator->__construct([Sabre\VObject\C ... }])
 6. /var/www/html/apps/dav/lib/CalDAV/CalDavBackend.php line 1220
    OCA\DAV\CalDAV\CalDavBackend->getDenormalizedData("BEGIN:VCALENDAR ... n")
 7. /var/www/html/apps/dav/lib/CalDAV/WebcalCaching/RefreshWebcalService.php line 132
    OCA\DAV\CalDAV\CalDavBackend->createCalendarObject(4, "d1cdc89d-ca91-4 ... s", "BEGIN:VCALENDAR ... n", 1)

I'm wondering: why might this particular line throw an error? It seems to me based on the main error message that the VALUE=PERIOD (which is in the specs) might not be recognised. Would that be possible?

(Also reported here: https://github.com/nextcloud/calendar/issues/4772)

Many thanks in advance. And apologies if I'm at the wrong address here.

DateTimeParser.php

Replace Z | (?: \+|-)(?: [0-9]{2}:[0-9]{2}) Into Z | (?: \+|-)(?: [0-9]{2}:?[0-9]{2})

Because some timezone entries are without the :

1. Bump dependencies in composer.json

2. Bump phpstan to level 6

3. WIP - fixup type declarations (test code)

4. ToDo - fixup type declarations (real code)

KDE KAddressBook has <x-crypto><allowed> to select which kind of email encryptions are allowed for the contact.

<?xml version=3D"1.0" encoding=3D"UTF-8" standalone=3D"no" ?>
<vcards xmlns=3D"urn:ietf:params:xml:ns:vcard-4.0">
  <vcard>
    <x-crypto>
      <allowed>
        <text>PGP/INLINE</text>
        <text>PGP/MIME</text>
        <text>S/MIME</text>
        <text>S/MIMEOpaque</text>
      </allowed>
      <signpref>
        <text>Never</text>
      </signpref>
      <encryptpref>
        <text>Always</text>
      </encryptpref>
    </x-crypto>
  </vcard>
</vcards>

When VCard->validate() is called, Sabre\VObject\Property\Text::getRawMimeDirValue() throws warning: strtr(): Argument #1 ($string) must be of type string, array given

https://github.com/sabre-io/vobject/blob/49dbd1bacba784025cc012fd7d908dd87a725914/lib/Property/Text.php#L142 Has an issue because $subItem is an array:

$item = array (
  0 => 
  array (
    'name' => '{urn:ietf:params:xml:ns:vcard-4.0}text',
    'value' => 'PGP/INLINE',
    'attributes' => 
    array (
    ),
  ),
  1 => 
  array (
    'name' => '{urn:ietf:params:xml:ns:vcard-4.0}text',
    'value' => 'PGP/MIME',
    'attributes' => 
    array (
    ),
  ),
  2 => 
  array (
    'name' => '{urn:ietf:params:xml:ns:vcard-4.0}text',
    'value' => 'S/MIME',
    'attributes' => 
    array (
    ),
  ),
  3 => 
  array (
    'name' => '{urn:ietf:params:xml:ns:vcard-4.0}text',
    'value' => 'S/MIMEOpaque',
    'attributes' => 
    array (
    ),
  ),
)

VObject parsed structure in PHP:

            [X-CRYPTO] => Array
                (
                    [0] => Sabre\VObject\Property\Unknown Object
                        (
                            [delimiter] => ,
                            [structuredValues:protected] => Array
                                (
                                    [0] => N
                                    [1] => ADR
                                    [2] => ORG
                                    [3] => GENDER
                                    [4] => CLIENTPIDMAP
                                    [5] => REQUEST-STATUS
                                )

                            [minimumPropertyValues:protected] => Array
                                (
                                    [N] => 5
                                    [ADR] => 7
                                )

                            [name] => X-CRYPTO
                            [group] => 
                            [parameters] => Array
                                (
                                )

                            [value:protected] => Array
                                (
                                    [0] => Array
                                        (
                                            [0] => Array
                                                (
                                                    [name] => {urn:ietf:params:xml:ns:vcard-4.0}text
                                                    [value] => PGP/INLINE
                                                    [attributes] => Array
                                                        (
                                                        )

                                                )

                                            [1] => Array
                                                (
                                                    [name] => {urn:ietf:params:xml:ns:vcard-4.0}text
                                                    [value] => PGP/MIME
                                                    [attributes] => Array
                                                        (
                                                        )

                                                )

                                            [2] => Array
                                                (
                                                    [name] => {urn:ietf:params:xml:ns:vcard-4.0}text
                                                    [value] => S/MIME
                                                    [attributes] => Array
                                                        (
                                                        )

                                                )

                                            [3] => Array
                                                (
                                                    [name] => {urn:ietf:params:xml:ns:vcard-4.0}text
                                                    [value] => S/MIMEOpaque
                                                    [attributes] => Array
                                                        (
                                                        )

                                                )

                                        )

                                    [1] => Array
                                        (
                                            [0] => Array
                                                (
                                                    [name] => {urn:ietf:params:xml:ns:vcard-4.0}text
                                                    [value] => Never
                                                    [attributes] => Array
                                                        (
                                                        )

                                                )

                                        )

                                    [2] => Array
                                        (
                                            [0] => Array
                                                (
                                                    [name] => {urn:ietf:params:xml:ns:vcard-4.0}text
                                                    [value] => Always
                                                    [attributes] => Array
                                                        (
                                                        )

                                                )

                                        )

                                )

which will support PHP 7.4 8.0 8.1 8.2 and have type declarations on parameters and return values etc as far as possible with features available in PHP 7.4.

If possible, increase the phpstan level to 6. That requires adding a lot of parameters and return type detail in PHPdoc (specially of the shape of arrays. When I do this locally, I get a longggg list of things reported. So it might take a while to sort all that out! I will try adjusting a few things and then report how it goes, and how big a job it seems.