Re: [reSIProcate-users] Privacy header parsing
That is what I was thinking. Also, since that exchange was carried out, we managed to get in touch with Jon and verify that it was supposed to be a single-value header.
Best regards, Byron Campen I didn't comment on that message because it didn't have any bearing on my immediate task at hand (looking for an 'id' priv-value, defined in RFC 3325), but I can see that it would affect a parser.
Generally it seems that the Privacy header format was not very well thought out - 'critical' would be a good candidate for a parameter to a set of priv-values - but I get the impression that the author of RFC 3323 has not intended the Privacy header to be multi-valued. Consider this for example:
"User agents SHOULD include a Privacy header when network-provided
privacy (as described in Section 3.3) is required. Note that some
intermediaries may also add the Privacy header to messages, including
privacy services. However, such intermediaries SHOULD only do so if
they are operating at a user's behest, for example if a user has an
administrative arrangement with the operator of the intermediary that
it will add such a Privacy header. An intermediary MUST NOT modify
the Privacy header in any way if the 'none' priv-value is already
specified."
What I'll probably do is to create a ParserCategory that grabs the whole set of priv-values without attempting to get any parameters, and can be asked to return a Tokens with the priv-values. Then it would be less important if the header is multi-valued or not.
Or is there a better way?
Rgds,
Mats
-----Original Message-----
From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
Sent: Tue 2008-10-07 22:26
To: Mats Behre
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] Privacy header parsing
I will direct your attention to http://list.resiprocate.org/archive/resiprocate-devel/msg06465.html
.. I do see your point about the parameter parsing though. We probably
need to define a new ParserCategory for this.
Best regards,
Byron Campen
>
> Hi,
>
> Has there been any work to solve the issue reported in http://list.resiprocate.org/archive/resiprocate-devel/msg06463.html?
>
> As far as I can tell the root of the problem is that the Privacy
> value is of type Token, but the tokens are separated by ';' instead
> of ',', so only the first one is parsed as a token, and the rest as
> parameters. This would be possible to code around, but the 'user'
> parameter is defined to have a value (DataParameter), so the parser
> throws an exception when there is no value.
> I guess I could define another value type for Privacy that doesn't
> attempt to parse parameters, but if the issue has already been
> solved I'd prefer not to. (Currently I'm running 1.3.4.)
>
> Rgds,
> Mats
>
> _______________________________________________
> resiprocate-users mailing list
> resiprocate-users@xxxxxxxxxxxxxxx
> List Archive: http://list.resiprocate.org/archive/resiprocate-users/
|
Attachment:
smime.p7s
Description: S/MIME cryptographic signature