On 05.05.2014, at 14:42, Patrick Ohly <patrick.o...@intel.com> wrote:
>>> Now, the conceptual problem with "X-ABLabel parameter" is that a quoted >>> string cannot contain double quotes. It is probably rare that a user >>> enters double quotes as part of a label, but it cannot be ruled out >>> either. Line breaks are also only allowed in property values and not >>> parameter values. > > I've looked into TMimeDirProfileHandler::generateValue() some more to > understand under which circumstances libsynthesis uses quoted strings > (with double quotes at start and end) as parameter value. At first > glance it doesn't seem to do that at all. Instead special values are > escaped with backslash. > > item29.X-ABLabel:custom-label5\nUmlaut-ä\nSemicolon\; > -> > X-ABRELATEDNAMES;X-ABLabel=custom-label5\nUmlaut-ä\nSemicolon\;:custom > relationship > > Where is it specified that the backslash escape mechanism can be used in > parameter values? That's a tough question :-) You are probably right regarding the specs. What I faintly remember is that the problem of escaping parameter values came into the scene when Oracle's put some lengthy internal ID into parameters. These IDs had all sorts of nasty characters. That's when the parameter value escaping using backslash was implemented. What I don't remember and also did not find in the history is the rationale for using the backslash. Most probably, their ID contained doublequotes, so doublequouting them would not have helped. I know we discussed variants with the Oracle guys. Also, probably this was pre-iCalendar, and the vCalendar "specs" were more than vague in many of these details. So probably this was just the solution we found for vCalendar and it was never checked to conform with RFC2425 later. > http://tools.ietf.org/html/rfc2425#page-5 says: > > > param = param-name "=" param-value *("," param-value) > > param-name = x-name / iana-token > > param-value = ptext / quoted-string > > ptext = *SAFE-CHAR > > SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII > ; Any character except CTLs, DQUOTE, ";", ":", "," > > My reading of that is that special characters must not appear in a ptext > at all, not even when escaped with backslash. One has to use a quoted > string, which (unfortunately) cannot hold all characters either. Especially the double quote itself remains a problem. > IMHO libsynthesis is currently producing broken vCards. I consider > changing the code so that it uses quoted strings if it detects unsafe > characters in the value and filters out invalid ones. "unsafe" would be > more conservative than in the RFC itself and also include spaces, to > work around the EDS parser bug. Makes sense. Of course, TMimeDirProfileHandler::parseValue() would need to be updated as well. To maximize backwards compatibility I would however still generate backslash escapes when the value actually contains a doublequote, newline or backslash itself. And the parser should generally allow backslash-escaped characters. The only deviation from RFC2425 would be that values containing literal backslashes would not transmit according to the standard. Best Regards, Lukas
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
