I think the hole case is typical example of: "be liberal on what you receive, but be strict on what you send". Thus IMO both implementations, the gateway and the proxy, should be fixed.

Jiri: sure you can refer to the generic extension. That allows any header with any value in a SIP message. But then you can not count on the rules any more which apply only to the non-generic headers (here how to process the MF header). Otherwise you would be allowed to put any content into any known header. But I agree that the RFC BNF should be extended to allow WS also at the end of a line. Sorry but I do not agree to implement a RFC compliance test which is IMHO not covered by the RFC (yet).

Regards Nils

On Tuesday 16 November 2004 13:08, Jiri Kuthan wrote:

The BNF in RFC3261 is actually ambiguous. As you may see, the extension header spec which matches Max-forwads too is more explicit about use of LWS.

header-name = token header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)

I think this is a pefect case against a UAS for the SIP Forum testing suite. (Nils on cc)

-jiri

At 12:48 PM 11/16/2004, Martin Koenig wrote:

...

Hello,

I think the white space is not legal in 3261. Please take a look at the message below.

Best regards, Martin

-----Original Message----- From: Attila Sipos [mailto:Attila.Sipos@vegastream.com] Sent: Tuesday, November 16, 2004 12:01 PM To: Martin Koenig; sip-implementors@cs.columbia.edu Subject: RE: [Sip-implementors] Whitespace after value in SIP header field

Hi,

One of the headers in the posting to the SERusers mailing list is:

Max-Forwards: 8 .

According to RFC3261 Max-Forwards is defined as:

Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT

and DIGIT (from RFC2234) is:

   DIGIT       =  "0" / "1" / "2" / "3" / "4" / "5" / "6" /
                      "7" / "8" / "9"

So, you can have a space between the colon and the first digit but you're not allowed any spaces after or between any digits and you're certainly not allowed a '.' character.

Regards,

Attila

Attila Sipos Software Engineer http://www.vegastream.com/

...

-----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu]On Behalf Of Martin Koenig Sent: 16 November 2004 09:56 To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] Whitespace after value in SIP header field

Hello,

please check the following posting to the SERusers mailinglist:

http://lists.iptel.org/pipermail/serusers/2004-September/011580.html

What do you think? Is the white space after the header field value according to 3261 or not?

Best regards, Martin

---

Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

-- Jiri Kuthan http://iptel.org/~jiri/

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

On Wednesday 17 November 2004 18:42, Jiri Kuthan wrote:

At 10:13 PM 11/16/2004, Nils Ohlmeier wrote:

...

Sorry but I do not agree to implement a RFC compliance test which is IMHO not covered by the RFC (yet).

Scope of SFTF is actually not spell-checking RFC compliance but more general, interoperability.

Yes that is true. But up to now there is no single test in STFT implemented which is not 100% covered by the RFC.

See http://www.ietf.org/internet-drafts/draft-ietf-sipping-torture-tests-04.txt for what it may be. The receiver should be liberal and if they don't understand something, they should skip it (as opposed to denying a request).

I know it :-) Only a very small subset of this draft is implemented in SFTF. And for every of these implemented tests it is IMO absolutely clear from the RFC how the UA should react. This is not the case for spaces at the end of the MF header or any header in general. We can discuss to add a new section of optional tests which should be passed to improve interoperability, but which are not mandatory because they are not (yet) covered by a RFC. But I'll not make such a dession on my own.

Greetings Nils