Subject: Yet another grammar related question

From: [email-masked]
Date: Tue, 7 Dec 1999 21:34:37 +0530

Hi ,
Please refer to "SIP torture tests(Legal but not likely implemented)" of
the 2nd bake off.

Would someone please clarify the following point noted there:

Unknown parameters of known headers -

What exactly does the above mean ? Does it mean that this test involves
adding any arbitrary parameter to any Header ?
For example, if Allow is defined as
Allow: 1#Method
then if a message has
Allow: OPTIONS CANCEL ;tux=hedwig

then is <;tux=hedwig> supposed to be the unknown param of known headers and
 is hence legal ? I hope this is not the intention ?
(In that case any garbage after any header is legal..)

or is it that
Allow: OPTIONS CANCEL GOOGLE
then GOOGLE, although an unknown method, is a legal unknown param of Allow
? That is , a format which the grammar supports
but the value of which is not (maybe) understood/logical

The reason I ask this is that in test9.txt  (in the 2ndbakeoff) I saw:

Authorization: Super-PGP ajsohdaosdh0asyhdaind08yasdknasd09asidhas0d8

but according to the specs.

Authorization          =        "Authorization" ":" credentials
credentials             =        basic-credentials | (auth-scheme
#(auth-params))
basic-credentials =       "Basic" SP basic-cookie
auth-param             =        token "=" string
auth-params      =      token "=" string

So above example maps to auth-scheme #(auth-params)

However, the ajsoh.... after it is not token=string, but is token.

Now is this really valid  ? (ie test 9.txt) ? And if its valid- does the
above qualify as "Unknown parameters of known headers " ???

Also, date in RFC states that it should be in GMT format but EDT has been
used too.

Now I totally agree that we should be lenient on input, but I strongly
stand by the fact that lets make the grammar as lenient as possible
without specfying a "fixed" grammar and deviating way off from it.

Finally, are there any changes being made to the grammar n the upcoming SIP
 RFC to try and incorporate as many major tracked
deviations  ? (Id be glad to point out where all there has been total
disrespect for the grammar :-)

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 07 Dec 1999 15:01:50 -0500

> adding any arbitrary parameter to any Header ?

No, of course not. Only those headers where extensions are allowed, such
as Contact.

> However, the ajsoh.... after it is not token=string, but is token.

You're right on that one. Good call. A better example would have been:

Authorization: Super-PGP response="aosjkndapojsbnda;ojsd",
algorithm=SHA-1

> Also, date in RFC states that it should be in GMT format but EDT has been

Thats a mistake. Its GMT only. Where did you see EDT?

> disrespect for the grammar :-)

The aim is to not do this if possible. I think the only changes (they're
fixes actually) so far is that extension-param was left off of one of
the headers, Via I think. And also that the PGP grammar isn't consistent
with the general grammar for the Authorization related headers.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com