Subject: [Sip] SIPit 21: BNF and DIGEST authentication

From: Robert Sparks <[email-masked]>
Date: Mon, 19 Nov 2007 15:40:33 -0600

We are _still_ seeing interoperability problems because of quotes  
around the qop parameter value in challenges and responses.

What's specified now is that quotes MUST appear in challenges (it's a  
list of things) and MUST NOT appear in responses (it's a choice of  
one thing).

This causes lots of people to write broken code.

For the code that does work, this causes people to either build  
separate parsers for headers with the same name, using the knowledge  
of whether its a challenge or response to invoke the right parser, or  
to build parsers that don't follow the BNF we've provided.

Would it make more sense to change the BNF to allow the quotes  
optionally in either the challenge or the response?

Nobody that I've asked is actually re-using an HTTP parser for this,  
and nobody seems to be getting the number of values for the parameter  
wrong. Most of the folks I ask are building their parsers this way  
anyhow

What would be bad about making this change to the spec?

RjS

_______________________________________________
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: Jeroen van Bemmel <[email-masked]>
Date: Tue, 20 Nov 2007 00:44:45 +0100

Robert,

We cannot make the quotes optional in the challenge, but we could make 
them mandatory in both cases. That would at least be easier to get 
right. Parsers would still need to support unquoted responses though

Regards,
Jeroen

Robert Sparks wrote:
> list of things) and MUST NOT appear in responses (it's a choice of one 
> thing).
>
> wrong. Most of the folks I ask are building their parsers this way anyhow
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Nov 2007 20:43:24 -0500

Jeroen van Bemmel wrote:
> Robert,
> 
> We cannot make the quotes optional in the challenge,

technically, or for reasons of backward compatibility?

Technically it would be ok as long as there was only one in the list. 
(No commas.) But I guess you are stuck for backward compatibility.

> but we could make 

Technically you could make them optional in the response.
But again backward compatibility causes trouble.

I don't see how you can improve things without breaking backward 
compatibility.

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 27 Nov 2007 13:56:00 -0500

> We are _still_ seeing interoperability problems because of 
> quotes around the qop parameter value in challenges and responses.
> 
> What's specified now is that quotes MUST appear in challenges 
> (it's a list of things) and MUST NOT appear in responses 
> (it's a choice of one thing).
> 
> For the code that does work, this causes people to either 
> build separate parsers for headers with the same name, using 
> the knowledge of whether its a challenge or response to 
> invoke the right parser, or to build parsers that don't 
> follow the BNF we've provided.
> 
> Would it make more sense to change the BNF to allow the 
> quotes optionally in either the challenge or the response?

< snip >

> What would be bad about making this change to the spec?

For backward compatibility reasons, I don't think that the BNF should
change.

However I agree that it is a common problem.  If rfc3261bis or
rfc4475bis gets generated, maybe the problem could be highlighted with a
potential recommendation to accommodate such errant devices.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 29 Nov 2007 19:38:18 -0800

I'm worried that any change would break the things that currently  
work. Any idea of how existing equipment would react?

(yah, yah, with my individual contribute hat on - I hate typing this  
more than you hate reading it)

On Nov 19, 2007, at 1:40 PM, Robert Sparks wrote:

> What's specified now is that quotes MUST appear in challenges (it's  
> a list of things) and MUST NOT appear i If on the other hand this is  
something that tell the policy system what to do, it would need a  
good explanation around what the authorization process was that A and  
P used when receiving the 183.

Cullen <with my individual contributor hat on>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 29 Nov 2007 19:38:18 -0800

On Nov 19, 2007, at 1:40 PM, Robert Sparks wrote:

> a list of things) and MUST NOT appear in responses (it's a choice  
> of one thing).
>
> separate parsers for headers with the same name, using the  
> knowledge of whether its a challenge or response to invoke the  
> right parser, or to build parsers that don't follow the BNF we've  
> provided.
>
> Nobody that I've asked is actually re-using an HTTP parser for  
> this, and nobody seems to be getting the number of values for the  
> parameter wrong. Most of the folks I ask are building their parsers  
> this way anyhow
>

n responses (it's a choice  
> of one thing).
> separate parsers for headers with the same name, using the  
> knowledge of whether its a challenge or response to invoke the  
> right parser, or to build parsers that don't follow the BNF we've  
> provided.
>
> Nobody that I've asked is actually re-using an HTTP parser for  
> this, and nobody seems to be getting the number of values for the  
> parameter wrong. Most of the folks I ask are building their parsers  
> this way anyhow
>

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 29 Nov 2007 23:30:30 -0500

Equipments which are liberal in what they receive and strict in what
they send should not have problem with this change.

Sanjay 

>-----Original Message-----
>From: Cullen Jennings (fluffy) 
>Sent: Thursday, November 29, 2007 10:38 PM
>To: sip List
>Subject: Re: [Sip] SIPit 21: BNF and DIGEST authentication
>
>
>I'm worried that any change would break the things that 
>currently work. Any idea of how existing equipment would react?
>
>(yah, yah, with my individual contribute hat on - I hate 
>typing this more than you hate reading it)
>
>> 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
>
>
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip