On Tue, 2014-05-06 at 12:09 +0200, Lukas Zeller wrote: > 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.
In the patch that I just sent I substitute it with a single quote. > > 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. Done, see the patch in my other mail. > To maximize backwards compatibility I would however still generate > backslash escapes when the value actually contains a doublequote, > newline or backslash itself. This will cause problems with peer parsers which do implement backslash escaping. For example: TEL;X-ABLabel="some string \" more string":1234 The EDS parser will end the parameter at the backslash and then get confused (and rightly so!) by the " more string" text. > And the parser should generally allow backslash-escaped characters. Again, that would lead to issues. Consider: TEL;X-ABLabel="some string \":1234 If we allow escaping, the parameter continues and includes the property value. What could work is to allow escaping anything which is not a double quote and which cannot be stored in a normal quoted-string. The only downside is that this will get shown to users literally if the peer's parser does no unescaping. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
