Subject: [Sipping] 400 Bad Request Vs 416 Unsupported URI scheme.

From: [email-masked]
Date: Wed, 18 Jul 2007 12:48:35 +0530

Hi All,
  I have a query regarding sending a 400 or a 416 response by the 
application at UAS.
The UAS has got a response in which the Request-URI is in error for which 
my current
UAS frames a 416 response. But few of them here have the opinion that the 
UA should be 
responding with a 400 error response. Please let me know which response is 
to be sent 
out. 
   The request-URI under discussion is INVITE <sip:[email-masked] SIP/2.0 
wherein the "<>" are not allowed in Req-line according to RFC 3261.

Thanks and Regards,
 Preethi..
------------------------------------------------------------------------------
Preethi Sadasivan,
Software Engineer,
ARICENT ,
Bangalore.
tel: +91-80-41069118
------------------------------------------------------------------------------

***********************  Aricent-Private   ***********************
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Jul 2007 09:26:59 -0400

Preethi,

I don't see that 416 is appropriate to this particular error.

The request header is syntactically incorrect, so in a real sense it has 
no request URI. If you can't get a URI from it I don't see how you can 
complain that the scheme of the URI is unsupported. I expect that 416 
would be appropriate if you received:

   INVITE foo:[email-masked] SIP/2.0

The only way I can see you deciding on 416 is if your parser thought 
that the scheme was "<sip". But the syntax of a request header doesn't 
allow you to parse it that way.

	Paul

[email-masked] wrote:
> The UAS has got a response in which the Request-URI is in error for 
> which my current
> UAS frames a 416 response. But few of them here have the opinion that 
> the UA should be
> responding with a 400 error response. Please let me know which response 
> is to be sent
> out.
>    The request-URI under discussion is INVITE* **<*sip:[email-masked] 
> SIP/2.0* **>*
> ------------------------------------------------------------------------
>

---

From: "Xia, Zhi Feng \(Bruce\)" <[email-masked]>
Date: Wed, 18 Jul 2007 16:04:16 +0800

I vote for 416 – 400 is more like general error in the request like some critical information is missing or incorrect, while 416 is specifically for malformed SIP URI.

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: 2007年7月18日 15:19
To: [email-masked]
Subject: [Sipping] 400 Bad Request Vs 416 Unsupported URI scheme.

Hi All, 
  I have a query regarding sending a 400 or a 416 response by the application at UAS. 
The UAS has got a response in which the Request-URI is in error for which my current 
UAS frames a 416 response. But few of them here have the opinion that the UA should be 
responding with a 400 error response. Please let me know which response is to be sent 
out. 
   The request-URI under discussion is INVITE <sip:[email-masked] SIP/2.0 > 
wherein the "<>" are not allowed in Req-line according to RFC 3261.

Thanks and Regards,
Preethi..

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 18 Jul 2007 22:13:28 +0800

In the parsers point of view, there is a URI because there is a none 
white space after the method invite.   The normal behavior of the parser 
would be to assume that the uri scheme is the string right after the 
white space and before the semin-colon ":".  In this case it's "<sip:".  
It is enough for the parser at this point to decide that there is no use 
to continue parsing the URI since the scheme is not valid.  Thus, I 
think 416 is admissible in this case.

Paul Kyzivat wrote:
> The request header is syntactically incorrect, so in a real sense it 
> has no request URI. If you can't get a URI from it I don't see how you 
> can complain that the scheme of the URI is unsupported. I expect that 
> 416 would be appropriate if you received:
>
>> "DISCLAIMER: This message is proprietary to Aricent and is intended 
>> solely for the use of the individual to whom it is addressed. It may 
>> contain privileged or confidential information and should not be 
>> circulated or used for any purpose other than for what it is 
>> intended. If you have received this message in error, please notify 
>> the originator immediately. If you are not the intended recipient, 
>> you are notified that you are strictly
>> prohibited from using, copying, altering, or disclosing the contents 
>> of this message. Aricent accepts no responsibility for loss or damage 
>> arising from the use of the information transmitted by this email 
>> including damage from virus."
>>
>>

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 18 Jul 2007 10:33:13 -0400

On Wed, 2007-07-18 at 12:48 +0530, [email-masked] wrote:
>    The request-URI under discussion is INVITE<sip:[email-masked] SIP/2.0 > 

I would say 400, since the request line is syntactically invalid (I
believe that our parser would bail as soon as it saw the '<' because
it's not valid in a scheme name), but I don't see why it would matter
which you sent - the results should be identical either way.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/

---

From: Robert Sparks <[email-masked]>
Date: Wed, 18 Jul 2007 09:35:47 -0500

By that reasoning, you would respond with a 416 if you had an INVITE  
followed by line-noise (at least to a CRLF w/ enough SIP looking  
stuff behind it
that you could form a response).

scheme         =  ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

(according to both 3261 _and_  3986).

Your parser is probably being a little too forgiving to think <sip:  
is enough of a scheme that you should complain about it as a scheme.

This really is a syntax error and should be responded to as such.

RjS

On Jul 18, 2007, at 9:13 AM, [email-masked] wrote:

> In the parsers point of view, there is a URI because there is a  
> none white space after the method invite.   The normal behavior of  
> the parser would be to assume that the uri scheme is the string  
> right after the white space and before the semin-colon ":".  In  
> this case it's "<sip:".  It is enough for the parser at this point  
> to decide that there is no use to continue parsing the URI since  
> the scheme is not valid.  Thus, I think 416 is admissible in this  
> case.
>
>
> Paul Kyzivat wrote:
>> Preethi,
>>
>> The request header is syntactically incorrect, so in a real sense  
>> it has no request URI. If you can't get a URI from it I don't see  
>> how you can complain that the scheme of the URI is unsupported. I  
>> expect that 416 would be appropriate if you received:
>>
>> The only way I can see you deciding on 416 is if your parser  
>> thought that the scheme was "<sip". But the syntax of a request  
>> header doesn't allow you to parse it that way.
>>
>>     Paul
>>
>>>    The request-URI under discussion is INVITE*  
>>> **<*sip:[email-masked] SIP/2.0* **>*
>>> "DISCLAIMER: This message is proprietary to Aricent and is  
>>> intended solely for the use of the individual to whom it is  
>>> addressed. It may contain privileged or confidential information  
>>> and should not be circulated or used for any purpose other than  
>>> for what it is intended. If you have received this message in  
>>> error, please notify the originator immediately. If you are not  
>>> the intended recipient, you are notified that you are strictly
>>> prohibited from using, copying, altering, or disclosing the  
>>> contents of this message. Aricent accepts no responsibility for  
>>> loss or damage arising from the use of the information  
>>> transmitted by this email including damage from virus."
>>>
>>>

---

From: "Attila Sipos" <[email-masked]>
Date: Wed, 18 Jul 2007 15:35:31 +0100

416 is not for malformed SIP URI, it is for "Unsupported URI Scheme".
<sip: is not a URI - it's syntax doesn't match the SIP grammar:
scheme         =  ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
 
The scheme has to start with an alpha character, so starting with a < is
completely illegal.
 
400 would the correct response since if the message is illegal, it
is a Bad Request.

From: Xia, Zhi Feng (Bruce) [mailto:[email-masked]]
Sent: Wed 18/07/2007 09:04
To: [email-masked]; [email-masked]
Subject: RE: [Sipping] 400 Bad Request Vs 416 Unsupported URI scheme.

I vote for 416 - 400 is more like general error in the request like some critical information is missing or incorrect, while 416 is specifically for malformed SIP URI.

Sent: 2007?7?18? 15:19

Hi All, 

Thanks and Regards,
Preethi..

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Jul 2007 10:53:57 -0400

> think 416 is admissible in this case.

 From 3261 ABNF:

Request-Line   =  Method SP Request-URI SP SIP-Version CRLF
Request-URI    =  SIP-URI / SIPS-URI / absoluteURI
absoluteURI    =  scheme ":" ( hier-part / opaque-part )

When parsing "INVITE <sip:[email-masked] SIP/2.0 >" against that,
you are suggesting that it matches against absoluteURI, with a scheme of 
"<sip", which you don't support. But it doesn't match that because "<" 
isn't a valid character in scheme.

You might argue that 400 is also incorrect, because the message doesn't 
even parse as a request. In that case you would have to simply drop the 
message. Deciding it is a bad request is part of a parser error recovery 
scheme that at least allows you to send a response indicating something 
is wrong.

Having said all this, the main thing is that the request is indeed 
incorrect, regardless of what error you return. The main focus should be 
on getting the sender to fix its problem. Changing the response from 416 
to 400 isn't likely to cause the sender to suddenly recognize it is 
doing something wrong and automatically start doing the right thing.

	Paul

	Paul

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 18 Jul 2007 23:03:33 +0800

Hi Robert,

I agree.  It's a little too forgiving and that the URI is indeed 
syntactically incorrect.  However, its is still lighter to compare 
"<sip: " against known URI schemes than to launch a state machine to 
validate the scheme on a per character basis.   I would still say 416 is 
still "acceptable".  It's not equal to saying you can't go on further 
and have a clearer decision and respond with 400 Sorry < is not a valid 
character in a a URI scheme and thus your URI is syntactically Incorrect 
CRLF.  :-)  If the parser allows the extra work, then 400 definitely is 
the way to go in this case.   I agree with Scott.  400 or 416, it really 
does not matter.

Robert Sparks wrote:
> followed by line-noise (at least to a CRLF w/ enough SIP looking stuff 
> behind it
> Your parser is probably being a little too forgiving to think <sip: is 
> enough of a scheme that you should complain about it as a scheme.
>
>> white space after the method invite.   The normal behavior of the 
>> parser would be to assume that the uri scheme is the string right 
>> after the white space and before the semin-colon ":".  In this case 
>> it's "<sip:".  It is enough for the parser at this point to decide 
>> that there is no use to continue parsing the URI since the scheme is 
>> not valid.  Thus, I think 416 is admissible in this case.
>>
>>
>> Paul Kyzivat wrote:
>>> Preethi,
>>>
>>> has no request URI. If you can't get a URI from it I don't see how 
>>> you can complain that the scheme of the URI is unsupported. I expect 
>>> that 416 would be appropriate if you received:
>>>
>>> that the scheme was "<sip". But the syntax of a request header 
>>> doesn't allow you to parse it that way.
>>>
>>>     Paul
>>>
>>>> solely for the use of the individual to whom it is addressed. It 
>>>> may contain privileged or confidential information and should not 
>>>> be circulated or used for any purpose other than for what it is 
>>>> loss or damage arising from the use of the information transmitted 
>>>> by this email including damage from virus."
>>>>
>>>>

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 18 Jul 2007 23:05:03 +0800

Well said.  I agree.

Paul Kyzivat wrote:
> you are suggesting that it matches against absoluteURI, with a scheme 
> of "<sip", which you don't support. But it doesn't match that because 
> "<" isn't a valid character in scheme.
>
> You might argue that 400 is also incorrect, because the message 
> doesn't even parse as a request. In that case you would have to simply 
> drop the message. Deciding it is a bad request is part of a parser 
> error recovery scheme that at least allows you to send a response 
> indicating something is wrong.
>
> incorrect, regardless of what error you return. The main focus should 
> be on getting the sender to fix its problem. Changing the response 
> from 416 to 400 isn't likely to cause the sender to suddenly recognize 
> it is doing something wrong and automatically start doing the right 
> thing.
>
>     Paul
>
>     Paul
>
>
>> Paul Kyzivat wrote:
>>> Preethi,
>>>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 18 Jul 2007 10:26:28 -0500

Keep in mind that one thing that could happen is that the user agent  
receiving that 416 turns it into
a message that it puts in front of its user saying "You entered a bad  
URI scheme - try something else",
and that user provided sip:. That poor person  will be mightily  
confused.

RjS

On Jul 18, 2007, at 10:05 AM, [email-masked] wrote:

>>> none white space after the method invite.   The normal behavior  
>>> of the parser would be to assume that the uri scheme is the  
>>> string right after the white space and before the semin-colon  
>>> ":".  In this case it's "<sip:".  It is enough for the parser at  
>>> this point to decide that there is no use to continue parsing the  
>>> URI since the scheme is not valid.  Thus, I think 416 is  
>>> admissible in this case.
>>
>> From 3261 ABNF:
>>
>> you are suggesting that it matches against absoluteURI, with a  
>> scheme of "<sip", which you don't support. But it doesn't match  
>> that because "<" isn't a valid character in scheme.
>>
>> doesn't even parse as a request. In that case you would have to  
>> simply drop the message. Deciding it is a bad request is part of a  
>> parser error recovery scheme that at least allows you to send a  
>> response indicating something is wrong.
>>
>> incorrect, regardless of what error you return. The main focus  
>> should be on getting the sender to fix its problem. Changing the  
>> response from 416 to 400 isn't likely to cause the sender to  
>> suddenly recognize it is doing something wrong and automatically  
>> start doing the right thing.
>>
>>     Paul
>>
>>     Paul
>>
>>
>>> Paul Kyzivat wrote:
>>>> Preethi,
>>>>
>>>> The request header is syntactically incorrect, so in a real  
>>>> sense it has no request URI. If you can't get a URI from it I  
>>>> don't see how you can complain that the scheme of the URI is  
>>>> unsupported. I expect that 416 would be appropriate if you  
>>>> received:
>>>>
>>>>> addressed. It may contain privileged or confidential  
>>>>> information and should not be circulated or used for any  
>>>>> purpose other than for what it is intended. If you have  
>>>>> received this message in error, please notify the originator  
>>>>> immediately. If you are not the intended recipient, you are  
>>>>> notified that you are strictly

---

From: "Xia, Zhi Feng \(Bruce\)" <[email-masked]>
Date: Thu, 19 Jul 2007 09:07:44 +0800

But from another point of view 416 gives more accurate information to sender: your request URI is bad – 400 indicates bad request but it could be error anywhere inside the message.

From: Attila Sipos [mailto:[email-masked]] 
Sent: 2007年7月18日 22:36
To: Xia, Zhi Feng (Bruce); [email-masked]; [email-masked]
Subject: RE: [Sipping] 400 Bad Request Vs 416 Unsupported URI scheme.

completely illegal.

is a Bad Request.

Hi All, 

Thanks and Regards,
Preethi..

---

From: "STAELENS Nadine" <[email-masked]>
Date: Thu, 19 Jul 2007 09:26:35 +0200

You can always indicate this via the reason phrase.
 
See RFC 3261:
21.4.1 400 Bad Request

   The request could not be understood due to malformed syntax.  The
   Reason-Phrase SHOULD identify the syntax problem in more detail, for
   example, "Missing Call-ID header field".

Kind regards,
  Nadine.

From: XIA Bruce 
Sent: donderdag 19 juli 2007 3:08
To: Attila Sipos; [email-masked]; [email-masked]
Subject: RE: [Sipping] 400 Bad Request Vs 416 Unsupported URI scheme.

But from another point of view 416 gives more accurate information to sender: your request URI is bad - 400 indicates bad request but it could be error anywhere inside the message.

completely illegal.

is a Bad Request.

Hi All, 

Thanks and Regards,
Preethi..