Re: [reSIProcate] Accept-Contact gives parse exception

[Byron Campen <bcampen@xxxxxxxxxxxx>]

	On more thought, I can see how StringCategory might not work very  
well for _generating_ these headers. NameAddr is no better though. We  
could just write a really lightweight ParserCategory for this (hard- 
coded to emit a "*", followed by params).

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@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

Attachment: smime.p7s
Description: S/MIME cryptographic signature