Subject: RE: Repost: [Sip] Buggy example in RFC 3261

From: [email-masked]
Date: Thu, 2 Jan 2003 16:22:15 +0200

This is an extract from a discussion I had with Robert Sparks:

> >Yes, that was exactly what I asked. If its not so, what does an Expires
> >header in a 200 OK for a REGISTER mean?
>
>
>As I note above, with the current text an Expire header field has no meaning
>if it appears in a 200 response to a REGISTER request.

http://www.ietf.org/mail-archive/working-groups/sip/current/msg03602.html

Regards,
Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, January 02, 2003 7:01 AM
> To: Peter Päppinghaus
> Cc: [email-masked]
> Subject: Re: Repost: [Sip] Buggy example in RFC 3261
> 
> 
> Sorry for not responding. I did notice this. There is an 
> error here, as 
> you point out. What is NOT clear is whether the error is in 
> the example, 
> or in the normative text. For REGISTER requests, you can use 
> either the 
> Expires header field or the expires contact header field 
> parameter. It 
> seems odd that this same rule would not apply to REGISTER 
> responses. My 
> personal recollection was that either the Expires header field or the 
> expires contact param was OK for either request or response. This 
> doesn't match the normative text though.
> 
> Does anyone use the Expires header field and NOT the expires contact 
> param in REGISTER responses?
> 
> -Jonathan R.
> 
> Peter Päppinghaus wrote:
> > I have posted this earlier, but it seems to have gone
> > unnoticed.
> > 
> > Hi,
> > 
> > I believe to have stumbled on a buggy example in RFC 3261.
> > 
> > The 200 OK in the REGISTER example of RFC 3261, sec. 24.1 contains
> > an Expires header, but no expires parameter in the Contact header.
> > 
> > This violates RFC 3261, sec. 10.3, bullet 8:
> > "Each Contact value MUST feature an "expires" parameter
> >   indicating its expiration interval chosen by the registrar."
> > 
> > Regards,
> > 
> > Peter Paeppinghaus
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Jan 2003 01:34:39 -0500

Well, a decision needs to be made one way or another. Since its already 
in 3261, I would propose that we declare the example as buggy, and go 
with the existing normative text, even though it works differently than 
for requests.

-Jonathan R.

---

From: Peter Päppinghaus <[email-masked]>
Date: Sun, 05 Jan 2003 14:58:46 +0100

Two more remarks inline.

>>> if it appears in a 200 response to a REGISTER request.

This remark is not in line with the following text from RFC 3261,
section 10.2.4 Refreshing Bindings:
   "The 200 (OK) response from the registrar contains a list of Contact
    fields enumerating all current bindings.  The UA compares each
    contact address to see if it created the contact address, using
    comparison rules in Section 19.1.4.  If so, it updates the expiration
    time interval according to the expires parameter or, if absent, the
    Expires field value."

This clearly gives a meaning to the Expire header field in
200 for REGISTER.

>>> Sorry for not responding. I did notice this. There is an error here, 
>>> as you point out. What is NOT clear is whether the error is in the 
>>> example, or in the normative text. For REGISTER requests, you can use 
>>> either the Expires header field or the expires contact header field 
>>> parameter. It seems odd that this same rule would not apply to 
>>> REGISTER responses. My personal recollection was that either the 

To me this asymmetry between REGISTER and its 200 responses does not
seem so odd. On the one hand it is very likely that a UA registering
a set of contact addresses in one REGISTER would suggest the same
expiration interval for all of them. On the other hand the 200 for
such a REGISTER is required to list all current bindings, and there
is no reason why the bindings should all have the same expiration
time.

>>> Expires header field or the expires contact param was OK for either 
>>> request or response. This doesn't match the normative text though.
>>>

-- 
Dr. Peter Päppinghaus
Siemens AG            | Phone:    +49 89 - 722 40065
ICM N PG U ID A1      | Fax:      +49 89 - 722 58726
Hofmannstr. 51        | Visitors: Building 1713 / Room 714
D - 81359 München     | Email:    [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 05 Jan 2003 21:46:38 -0500

inline.

Peter Päppinghaus wrote:
>> Well, a decision needs to be made one way or another. Since its 
>> already in 3261, I would propose that we declare the example as buggy, 
>> and go with the existing normative text, even though it works 
>> differently than for requests.
>>
>> -Jonathan R.
>>

Yes, another inconsistency here.

>>>> example, or in the normative text. For REGISTER requests, you can 
>>>> use either the Expires header field or the expires contact header 
>>>> field parameter. It seems odd that this same rule would not apply to 

True enough, but the same processing would still work in either case.

Anyway, I would still propose to follow my suggestion and go with the 
normative text in bullet 8 of 10.3.

-Jonathan R.

---

From: Peter Päppinghaus <[email-masked]>
Date: Tue, 07 Jan 2003 09:28:41 +0100

inline.

Jonathan Rosenberg wrote:

>>> already in 3261, I would propose that we declare the example as 
>>> buggy, and go with the existing normative text, even though it works 

[snip]

> normative text in bullet 8 of 10.3.

This is also my personal preference.