Subject: [scim] http://tools.ietf.org/html/draft-ietf-scim-api-03#section-3.9

From: Julian Reschke <[email-masked]>
Date: Thu, 06 Mar 2014 12:33:29 +0100

Hi there,

I still find it irritating that the spec lists a certain set of HTTP 
status codes clients "SHOULD" handle.

Clients MUST handle status codes as per defined by HTTP. We have status 
code classes for the cases where a client doesn't know a specific one, 
so it can fallback to default behavior.

It's ok to have *examples* of status codes clients are likely to see, 
and to give guidance to servers which one to sent. But that's different 
from just listing a few and pretending that there are no others.

Best regards, Julian

---

From: Leif Johansson <[email-masked]>
Date: Thu, 06 Mar 2014 13:20:54 +0100

On 2014-03-06 12:33, Julian Reschke wrote:
> Clients MUST handle status codes as per defined by HTTP. We have
> status code classes for the cases where a client doesn't know a
> specific one, so it can fallback to default behavior.
>
> and to give guidance to servers which one to sent. But that's
> different from just listing a few and pretending that there are no
> others.
>
> Best regards, Julian
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
I've created issue 67 to track this

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Mar 2014 12:28:50 +0000

There are items that are still being cleaned up from the external scim 1 drafts to match IETF editorial styles. 

In this case at least some of table is more of an FYI and maybe should be expressed in non-normative language. Only when we are specifically profiling httpbis should the language be normative IMHO. 

Also. I plan update references to httpbis in next draft. Though i don't think the intent is to require httpbis. Comments from the group?

Phil

> On Mar 6, 2014, at 11:33, Julian Reschke <[email-masked]> wrote:
> 
> Hi there,
> 
> I still find it irritating that the spec lists a certain set of HTTP status codes clients "SHOULD" handle.
> 
> Clients MUST handle status codes as per defined by HTTP. We have status code classes for the cases where a client doesn't know a specific one, so it can fallback to default behavior.
> 
> It's ok to have *examples* of status codes clients are likely to see, and to give guidance to servers which one to sent. But that's different from just listing a few and pretending that there are no others.
> 
> Best regards, Julian
>

---

From: Leif Johansson <[email-masked]>
Date: Thu, 06 Mar 2014 13:41:04 +0100

>From a procedural standpoint I don't think we should hang on httpbis.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 6 Mar 2014 13:02:14 +0000

>> Also. I plan update references to httpbis in next draft. Though
>> I don't think the intent is to require httpbis. Comments from the group?
>

No delay issues here any more: the httpbis docs are all in the RFC
Editor queue, and should be RFCs by the end of April.

Barry

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Mar 2014 13:17:56 +0000

What is the best way to say httpbis is not a requirement and scim may be implemented on existing http 1.1 (2616) servers?

Ps. I understand that the intent here is to get people to update as was happening with TLS. 

Phil

---

From: Barry Leiba <[email-masked]>
Date: Thu, 6 Mar 2014 05:20:56 -0800

> What is the best way to say httpbis is not a requirement and scim
> may be implemented on existing http 1.1 (2616) servers?

There's no need to say it at all.  You simply say that you use HTTP,
and you give the reference to the httpbis p1 doc.  Say nothing about
versions at all.

Barry

---

From: Leif Johansson <[email-masked]>
Date: Thu, 06 Mar 2014 14:26:42 +0100

> Editor queue, and should be RFCs by the end of April.
ok fine but there are deployment issues to consider...

---

From: Leif Johansson <[email-masked]>
Date: Thu, 06 Mar 2014 14:27:08 +0100

> and you give the reference to the httpbis p1 doc.  Say nothing about
ok in that case it makes sense

---

From: Julian Reschke <[email-masked]>
Date: Thu, 06 Mar 2014 14:45:55 +0100

> ok fine but there are deployment issues to consider...

There shouldn't be any deployment issues. Care to elaborate?

(Note this is still HTTP/1.1)

Best regards, Julian

---

From: Leif Johansson <[email-masked]>
Date: Thu, 06 Mar 2014 17:42:05 +0100

> (Note this is still HTTP/1.1)
yep, barry explained that in a separate email, we're good