[reSIProcate] Accept-Contact gives parse exception

[Byron Campen]

	Why would the app ever call .value()? The value is utterly  
meaningless. It is just there to make things easier on existing parsers.

Best regards,
Byron Campen

> I'm not sure that StringCategory is a good idea since it pushes all
> the effort onto the application although it would certainly fix the
> reported issue. I think it would be relatively easy to specialize
> NameAddr to support the different BNF.
>
> On Wed, Apr 23, 2008 at 8:17 AM, Byron Campen  
> <bcampen at estacado.net> wrote:
>>         So, it looks like the various headers in 3841 have a  
>> completely
>> different BNF than the Contact header, and using NameAddr to  
>> represent them
>> is incorrect. First off, these headers always have a value of  
>> "*" (never a
>> name-addr or addr-spec). Secondly, Contact headers with '*' cannot  
>> have
>> params.
>>
>>         I suppose it would be acceptable to represent these as a
>> StringCategory (this would not ensure that the value was "*", but  
>> it seems
>> that there isn't really any reason to care, since the value is  
>> meaningless
>> anyhow).
>>
>>  Best regards,
>>  Byron Campen
>>
>>
>>
>>
>>> I tried out the 1.3 version, and following header line (directly  
>>> from
>>> RFC 3841) does not parse:
>>> Accept-Contact: *;mobility="mobile";methods="INVITE"
>>> The problem is probably that several headers use the NameAddress  
>>> without
>>> being strictly NameAddress, so we have different wildcard cases  
>>> with or
>>> without parameters.
>>>
>>> Björn A.
>>>
>>>
>>>
>>>
>>> --
>>> This communication is confidential and intended solely for the
>> addressee(s). Any unauthorized review, use, disclosure or  
>> distribution is
>> prohibited. If you believe this message has been sent to you in  
>> error,
>> please notify the sender by replying to this transmission and  
>> delete the
>> message without disclosing it. Thank you.
>>> E-mail including attachments is susceptible to data corruption,
>> interruption, unauthorized amendment, tampering and viruses, and  
>> we only
>> send and receive e-mails on the basis that we are not liable for  
>> any such
>> corruption, interception, amendment, tampering or viruses or any
>> consequences thereof.
>>>
>>> _______________________________________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel at resiprocate.org
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>
>>
>>
>> _______________________________________________
>>  resiprocate-devel mailing list
>>  resiprocate-devel at resiprocate.org
>>  https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20080423/ee13d67a/attachment.bin>