iCal LOCATION: param and value parsed incorrectly

Right. The whole question of what to do with the location part of the spec has to be figured out. The usual method is actually to have an id that refers to a VVENUE element that has complete location information and we don't yet have a way to create a VVENUE, but an alternate is a plain text field where you just type in an address (which is what I was assuming we would have in most cases) and for that you have no id, or it could be a url as in your example, and in that case the url could be the id. So we have to figure out which kind of 'location' we have to know what to do with it.

The current method is correct if the location field is an address, so it's not really a 'bug', it's more of a task to figure out what to do with this.

I've been making some changes to the ical parsing now that we're working on getting Feed API and the Feed Element Mapper working to parse ical feeds and I specifically added some adaptions so that it would handle the upcoming.org location format (which is an odd format that no one else uses).

So now LOCATION will be a text value if it's just a regular address, or it will be an array of UID and DESCRIPTION if it's one that provides both. And you can use Feed API and the Feed Element Mapper with the Date module mapper that is in progress to create nodes from an upcoming.org feed.

The fix then broke the iCal standard param ALTREP, that is now used by upcoming.com. A better fix is to correct the reg ex so that it doesn't break the param and value at the first ':' but at the first ':' not in a quoted string - param are allowed safe-char or quoted-strings.

preg_match('/([^;]+)(?:;((?:[^:]*)(?:".*")))?:(.+)$/', $line, $matches);

The patch attached fixes this, and then adds the ALTREP into the array. It only returns an array, just with value if that's all there is, rather than mixed string or array. However, I've put this as needs work because...

At the moment I can't see last.fm using the alternative param, but there are actually lots that can be permitted, and they could be found in feeds used with other properties. So would it be better if all properties returned:-

  array ( 
    PROPERTY NAME => array ( 
      VALUE => property value, string, array whatever much as now, 
      PARAM => array ( 
        PARAM-NAME => parameter value, , ,
      )
    )
  )

With that it should cover not customizing as each example is found. Are there any places, other than in the iCal Parser, that this could cause knock-ons to take into account?

Unfortunately the D6 version of this module is no longer supported, but we appreciate the time you put into this. If this problem is relevant for D7 too, please reopen the issue. Thanks.