Subject: [sipcore] RFC 4320: deprecation of non-INVITE 408 responses

From: Brett Tate <[email-masked]>
Date: Thu, 8 Apr 2010 05:36:42 -0700

Since it was raised within rfc3265bis discussion, I thought that I'd attempt to get clarity concerning RFC 4320's deprecation of non-INVITE 408 responses in case errata should be opened against RFC 4320.

RFC 4320 intentionally or unintentionally appears to have deprecated all non-INVITE 408 responses.  However I thought that I'd still ask, is the deprecation only applicable for Timer F expiration type situations (i.e. the reason for the deprecation)?

If not limited to Timer F expiration type situations, such a deprecation causes some ambiguity concerning shorter timeouts on other interfaces.  For instance, a received SUBSCRIBE is transformed into another protocol's FOO message.  The FOO transaction delivery expires after 1 second.  Can a 408 response (although 504 might be better per rfc3261) be sent for the SUBSCRIBE?  What about a B2BUA which using a short expiration (like 1 second) on the send side; can it send a 408 response or must it really start sending 504 or other response instead? 

Thanks,
Brett

---

From: Adam Roach <[email-masked]>
Date: Thu, 08 Apr 2010 13:21:39 -0500

[as chair]

On 4/8/10 7:36 AM, Brett Tate wrote:
> RFC 4320 intentionally or unintentionally appears to have deprecated all non-INVITE 408 responses.

It was intentional, AFAIK.

>    However I thought that I'd still ask, is the deprecation only applicable for Timer F expiration type situations (i.e. the reason for the deprecation)?
>    

That's a good question -- perhaps Robert can weigh in on this.

> If not limited to Timer F expiration type situations, such a deprecation causes some ambiguity concerning shorter timeouts on other interfaces.  For instance, a received SUBSCRIBE is transformed in…

/a

---

From: Robert Sparks <[email-masked]>
Date: Thu, 8 Apr 2010 13:52:50 -0500

> It was intentional, AFAIK.

It was quite intentional.

> That's a good question -- perhaps Robert can weigh in on this.
408's semantics in 3261 are clearly bound to the transaction machinery. The other cases you are describing should use a different response code.

---

From: Brett Tate <[email-masked]>
Date: Thu, 8 Apr 2010 12:46:06 -0700

> 408's semantics in 3261 are clearly bound to the transaction 
> machinery. The other cases you are describing should use a 
> different response code.

If 408's semantics were so clear, I'd think RFC 3398, B2BUAs, and etcetera would not have generated or documented to generate a 408 response based upon another interfaces timeouts or receipt of 408.

Should errata be opened against RFC 3398?

Thanks for the response,

Brett

---

From: Robert Sparks <[email-masked]>
Date: Thu, 8 Apr 2010 15:32:54 -0500

We're talking about the non-INVITE transaction.
I think what you're looking at in 3398 is INVITE oriented (408's for INVITE have a broader meaning).

RjS

---

From: Brett Tate <[email-masked]>
Date: Fri, 9 Apr 2010 02:27:26 -0700

I am indicating that the logic that used to dismiss my concern over deprecating all non-INVITE 408 responses is incorrect.

Per RFC 3261, a 408 Request Timeout response to INVITE has no different meaning from a 408 Request Timeout to non-INVITE.  A request timeout is a request timeout. 

RFC 3261 section 21.4.9: "The server could not produce a response within a suitable amount of time, for example, if it could not determine the location of the user in time.  The client MAY repeat the request without modifications at any later time."

RFC 4320 unfortunately deprecated all 408 responses to non-INVITE instead of only the use case where sending the 408 isn't desirable.

Since RFC 4320 unfortunately deprecated 408 Request Timeout responses to non-INVITE, what response does the working group want to be sent to indicate "Request Timeout" when the timeout occurs quickly (like after 1 second) instead of after long delay associated with rfc4320/rfc4321's use case?  Is 504 Server Time-out the best alternative to indicate Request Timeout?

I would rather see RFC 4320's 408 deprecation be limited to appropriate use case instead of defining or using another response code to indicate Request Timeout.

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Thursday, April 08, 2010 4:33 PM
> To: Brett Tate
> Cc: Adam Roach; SIPCORE
> Subject: Re: [sipcore] RFC 4320: deprecation of non-INVITE 408
> responses
> 
> > If 408's semantics were so clear, I'd think RFC 3398, B2BUAs, and
> etcetera would not have generated or documented to generate a 408
> response based upon another interfaces timeouts or receipt of 408.
> >