Subject: Re: [SIP] Conflict between Contact Header definition and example

From: [email-masked]
Date: Thu, 12 Apr 2001 18:21:07 +0530

bob> Adding an optional "expires=0" parameter to the grammar would not
break any
bob> existing implementations. I suspect there may be some implementations
that
bob> have used solution 2.

Well, the moment you add new rules to the grammar there is always a chance
someone will break.
This is different from adding new tokens which comply to the generic ABNF.
In some cases it may be worth it - but I dont feel so in this case,
especially when
there is another way to do it - which is already complaint to the existing
ABNF .
If solutions have used the extra parameter after Contact *, they must know
that its
possible that a 3rd party registrar might not recognize it, since its not a
part of the standard.
So its not reasonable to say it will work always.

regds
Arjun
--
Arjun Roychowdhury @ Hughes Software Systems

"Bob Penfield" <[email-masked]> on 04/12/2001 06:15:34 PM

To:   archow, "Henning G. Schulzrinne" <[email-masked]>
cc:   "Beereddy, Srini" <[email-masked]>, [email-masked]

Subject:  Re: [SIP] Conflict between Contact Header definition and example

----- Original Message -----
From: <[email-masked]>
To: "Henning G. Schulzrinne" <[email-masked]>
Cc: "Beereddy, Srini" <[email-masked]>; <[email-masked]>
Sent: Thursday, April 12, 2001 1:53 AM
Subject: Re: [SIP] Conflict between Contact Header definition and example

>
>
>
> hgs> What do implementations do:
> hgs> 1) two headers (Expires: 0  and Contact: *)
> hgs> 2) one header: (Contact: *;expires: 0)
> hgs> 3) ignore the * and just use Expires: 0 [I doubt this is common...]
> hgs>
> hgs> I suspect the solution will be to allow  ;expires=something or just
> hgs> ;expires=0 with *.
>
> But this solution would break the already existing grammar if we allow
> an expires parameter with a Contact *. Since
> Contact: *
> Expires: 0
> has the same effect as Contact:*; expires=0 and it already exists
> without breaking the current grammar.
>  - my take would be to keep it as it and disallow expires param in
contact
> *.
> (solution 1 )

Adding an optional "expires=0" parameter to the grammar would not break any
existing implementations. I suspect there may be some implementations that
have used solution 2.

>
> regds
> Arjun
> --
> Arjun Roychowdhury @ Hughes Software Systems
>
>
> "Beereddy, Srini" wrote:
> >
> > There is a conflict between the "Contact" header definition and an
> example
> > of it in the section 6.38 2nd paragraph, 2nd line
> >
> > "Contact: * ;expires: 0".
> >
> > According to the definition of Contact header, it can have a "*" or
list
> of
> > (( name-addr | addr-spec ) *( ";" contact-params ) ).
> >
> > The "expires" parameter is part of "contact-params" which can only be
> > present ( name-addr | addr-spec ). So the example in the section is
6.38
> is
> > wrong.
> >
> > For a quick reference I have added the 2nd paragraph of section 6.38
and
> > definition of the Contact header
> >
> > thanks,
> > Srini Beereddy,
> > Trillium Digital Systems, an Intel Company.
> >
> > section 6.38 2nd paragraph
> > ==========================
> >    A REGISTER request MAY include this header field when deleting
> >    registrations with "Contact: * ;expires: 0". The Retry-After value
> >    then indicates when the user might again be reachable. The registrar
> >    MAY then include this information in responses to future calls.
> >
> > Contact Header
> > ==============
> >
> > Contact = ( "Contact" | "m" ) ":"
> >     ("*" | (1# (( name-addr | addr-spec ) *( ";" contact-params ) )))
> >
> >    name-addr      = [ display-name ] "<" addr-spec ">"
> >    addr-spec      = SIP-URL | URI
> >    display-name   = *token | quoted-string
> >
> >    contact-params = "q"       "=" qvalue
> >                   | "action"  "=" "proxy" | "redirect"
> >                   | "expires" "=" delta-seconds | <"> SIP-date <">
> >                   | contact-extension
> >
> >    contact-extension = generic-param
> >    qvalue            = ( "0" [ "." 0*3DIGIT ] )
> >                      | ( "1" [ "." 0*3("0") ] )
> >
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementor's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to
> > [email-masked] with "subscribe" in the body.
>
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> [email-masked] with "subscribe" in the body.
>
>
>
>
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> [email-masked] with "subscribe" in the body.
>

Bob
d:-)

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to
[email-masked] with "subscribe" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Thu, 12 Apr 2001 09:26:04 -0500

>
>Thanks for pointing this out. I would say that
>
>Contact: *
>Expires: 0
>
>would be sufficient. Indeed, is there any reasonable use for the * URL
>beyond expiration, i.e., 

I don't see one immediately.

>I'm assuming that somethig like
>
>Contact: *
>Expires: 3600
>
>would not be allowed. 

Actually, we allow it. However, I don't encourage this 
behavior :)

>
>What do implementations do:
>1) two headers (Expires: 0  and Contact: *)

This means wipe out all exising Contact:'s 
to us.

>2) one header: (Contact: *;expires: 0)

This is very ugly. I would prefer the two header version.
(Though this will work)

>3) ignore the * and just use Expires: 0 [I doubt this is common...] 

I hope no one does this.

>
>I suspect the solution will be to allow  ;expires=something or just
>;expires=0 with *.

I would prefer not allowing any parameters at all for the 
wildcard.

/sean