< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] RFC 3455 headers and parameters


Hi all,
I'm sorry but in my previous pull request I made a mistake.
As I wrote in my comment to new commit, even if a parameter name is known in 
one item scope (for example ttl in Via), it can be unknown in another one (for 
example ttl in Token).
So, ExtensionParameter constructor cannot throw exception if name is not 
unknown. Throwing an execption testParserCategories didn't pass.
Regards,
Dario.

-----Original Message-----
From: Dario Bozzali 
Sent: venerdì 19 settembre 2014 11.30
To: 'Daniel Pocock'
Cc: 'slgodin@xxxxxxxxx'; resiprocate-devel@xxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] RFC 3455 headers and parameters

Hi Daniel,
I started looking at the code and, in my opinion, there is an asymmetry between 
ExtensionHeader and ExtensionParameter.
In ExtensionHeader constructor we use an assert if header name is not unknown, 
but the same check is not done in ExtensionParameter constructor even if we 
assume that parameter name is unknown when we use ExtensionParameter in 
ParserCategory.
I suggest to add a check in both constructors and throw an exception if header 
or parameter name is not unknown.
In ExtensionParameter we could add ExtensionParameter::Exception inner class 
(symmetric to ExtensionHeader::Exception).
I updated pull request at https://github.com/resiprocate/resiprocate/pull/6.
Regards,
Dario.

-----Original Message-----
From: Daniel Pocock [mailto:daniel@xxxxxxxxxx] 
Sent: venerdì 19 settembre 2014 10.20
To: Dario Bozzali
Cc: 'slgodin@xxxxxxxxx'; resiprocate-devel@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] RFC 3455 headers and parameters

On 19/09/14 09:46, Dario Bozzali wrote:
> Hi Daniel,
> I created the separate pull request for project file.
> It can be consulted at the following link:
> https://github.com/resiprocate/resiprocate/pull/7

Great, I will let Scott look at that as he is using Windows heavily, my focus 
is mainly Linux

Dario, did you start making any change to the ExtensionHeader constructor or 
should I go and do that fix before pull request 6 is accepted?