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

Re: [reSIProcate] Accept-Contact gives parse exception


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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >
>
>
> _______________________________________________
>  resiprocate-devel mailing list
>  resiprocate-devel@xxxxxxxxxxxxxxx
>  https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>