Monica Ingudam wrote: > Hi Peter, > > So, should a 200 response of REGISTER with Expires header > field present but expires parameter not present in the > Contact header field be treated as an invalid response ? > > I feel that It should not be treated as an invalid response.
That is a different question, which was not my primary concern. My primary concern was to point to an inconsistency within RFC 3261 which ought to be resolved. So in that sense a 200 OK to REGISTER with Expires header is a faulty response. On the other hand your concern how to treat such a faulty response is certainly a valid concern. My view is to follow the guideline "as sender comply with the protocol rigidly, as receiver be forgiving with faults of other entities (if possible)". Which would mean in this case, since the receiver can make good sense of this faulty 200 OK, it should be forgiving and accept it as if it were valid. > Regards > Monica Ingudam > Huawei Technologies, Bangalore > > >>>>-----Original Message----- >>>>From: Peter Pa ppinghaus <[EMAIL PROTECTED]> >>>>[mailto:Peter Pa ppinghaus <[EMAIL PROTECTED]>] >>>>Sent: Wednesday, November 20, 2002 3:55 PM >>>>To: [EMAIL PROTECTED] >>>>Cc: [EMAIL PROTECTED] >>>>Subject: Re: [Sip-implementors] Re: 2 nits >>>> >>>> >>>>Hi Monica, >>>> >>>>see my comments inline. >>>> >>>>Regards, >>>> >>>>Peter Paeppinghaus >>>> >>>>Monica Ingudam wrote: >>>> >>>> >>>>>Hi Peter, >>>>> >>>>>The duration of the validity of the Contact URI can be indicated >>>>>through an Expires header field or an expires parameter in the >>>>>Contact header field. >>>>> >>>>>So I think that the 200 response of REGISTER in the >>>>> >>example should >> >>>>>be acceptable since it contains the Expires header,Even >>>>> >>>>though RFC 3261 >>>> >>>>>Sec. 10.3, bullet 8 states that "Each Contact value MUST >>>>> >>>feature an >>> >>>>>"expires" parameter indicating its expiration interval >>>>> >>>chosen by the >>> >>>>>registrar." >>>>> >>>>>Maybe,the same rule stated in Sec. 10.2.1.1 (2nd Para) >>>>> >>>>should be valid >>>> >>>>>for 200 response of REGISTER. >>>>> >>>> >>>>Well, yes, one could make sense of it. But MUST is MUST, and the >>>>protocol designers certainly had reasons for making it >>>> >>MUST. IMHO an >> >>>>example given in an RFC should conform to the MUSTs of that >>>> >>>same RFC. >>> >>>> >>>>>Regards >>>>>Monica Ingudam >>>>>Huawei Technologies, Bangalore >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>[Sip-implementors] 2 nits >>>>>>Peter P?ppinghaus [EMAIL PROTECTED] >>>>>><mailto:peter.paeppinghaus%40siemens.com> >>>>>>Fri, 08 Nov 2002 15:50:41 +0100 >>>>>>Hi, >>>>>> >>>>>>I believe to have stumbled on two bugs in examples. >>>>>> >>>>>>1) Quotation from draft-ietf-sipping-reg-event-00.txt, p. 18: >>>>>> >>>>>> "Later on, the user registers (5): >>>>>> >>>>>> REGISTER sip:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> SIP/2.0 >>>>>> Via: SIP/2.0/UDP pc34.bar.com;branch=z9hG4bKnaaff >>>>>> From: sip:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>;tag=99a8s >>>>>> To: sip:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>>>> Call-ID: [EMAIL PROTECTED] >>>>>> >>><mailto:[EMAIL PROTECTED]> >>> >>>>>> CSeq: 9976 REGISTER >>>>>> Contact: sip:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>" >>>>>> >>>>>> The Request-URI in this example violates RFC 3261, >>>>>> >>sec. 10.2: >> >>>>>> "The userinfo and "@" components of the SIP URI MUST NOT >>>>>>be present." >>>>>> >>>>>>2) 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 -- Dr. Peter Pa"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 PROTECTED] _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
