Subject: [scim] attribute name questions on draft-ietf-scim-core-schema-01

From: Phil Hunt <[email-masked]>
Date: Tue, 4 Jun 2013 13:03:53 -0700

Are attribute names cases sensitive? (eg. costCenter vs. costcenter)

When schema is extended what are the limitations on attribute names (e.g. are spaces allowed)?  

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Erik Wahlström <[email-masked]>
Date: Wed, 5 Jun 2013 08:28:40 +0000

Hi,

The spec don't really say anything about it. We should add something in secion 10.  Resource Schema when we talk about attributes.name. Currently description is only "The attribute's name.".

IMHO the attributes are case sensitive and any extensions should be forced to use camelCase. No spaces. 

Don't really see the upside of having it the other way and it's better to stay strict and well defined where we can.

/ Erik

On Jun 4, 2013, at 10:03 PM, Phil Hunt wrote:

> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Jun 2013 12:12:23 -0700 (PDT)

I too like camelCase.  However I would be concerned if we start to have issues because UserName is different from Username is different from userName. Ugh.

I propose that for the purposes of SCIM, that attribute names be case insensitive but that servers return names in camel-case to keep things REST friendly.

I think it is also easier for those implementers that are building on top of LDAP where LDAP is not case sensitive on names.

Should someone log another task/case?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Erik Wahlström <[email-masked]>
Date: Fri, 7 Jun 2013 11:13:04 +0000

Hi,

It's much easier to to parsing when it's strictly defined. At least depending on your preferred language / json parser. An example in plain javascript.

In the following the log will output "Babs".
var json = '{"firstName":"Babs"}';
var obj = JSON.parse(json);
console.log(obj.firstName);

In this example the name of the argument firstName is nor Firstname instead. The code will not find the attribute and you will get an "undefined". 
var json = '{"Firstname":"Babs"}';
var obj = JSON.parse(json);
console.log(obj.firstName);

I'm not saying you shouldn't do more parsing then that on a scim resource, but I don't see that it's enough upside to allow it.

/ Erik

---

From: Phil Hunt <[email-masked]>
Date: Fri, 7 Jun 2013 05:47:42 -0700

It might be something that servers should normalize so clients don't have an issue?

Phil

---

From: Mark Diodati <[email-masked]>
Date: Fri, 7 Jun 2013 14:38:40 -0500

+1. For clarity and consistency, it would be great to have case
sensitivity.

-----Original Message-----
From: Erik Wahlström [mailto:[email-masked]]
Sent: Friday, June 07, 2013 6:13 AM
To: Phil Hunt
Cc: [email-masked] WG
Subject: Re: [scim] attribute name questions on
draft-ietf-scim-core-schema-01

Hi,

It's much easier to to parsing when it's strictly defined. At least
depending on your preferred language / json parser. An example in plain
javascript.

In this example the name of the argument firstName is nor Firstname
instead. The code will not find the attribute and you will get an
"undefined".
var json = '{"Firstname":"Babs"}';
var obj = JSON.parse(json);
console.log(obj.firstName);

I'm not saying you shouldn't do more parsing then that on a scim resource,
but I don't see that it's enough upside to allow it.

/ Erik

On Jun 6, 2013, at 9:12 PM, Phil Hunt wrote:

> I too like camelCase.  However I would be concerned if we start to have
issues because UserName is different from Username is different from
userName. Ugh.
>
> I propose that for the purposes of SCIM, that attribute names be case
insensitive but that servers return names in camel-case to keep things
REST friendly.
>
> I think it is also easier for those implementers that are building on
top of LDAP where LDAP is not case sensitive on names.
>> The spec don't really say anything about it. We should add something in
secion 10.  Resource Schema when we talk about attributes.name. Currently
description is only "The attribute's name.".
>> Don't really see the upside of having it the other way and it's better
to stay strict and well defined where we can.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 7 Jun 2013 12:43:54 -0700

Mark,

Are you saying you want case-sensitive?  IOW   UserName <> Username <> userName <> username

If case-sensitive on server-side, the concern would be a profile could end up with different values for Username and username.

Yet, from an information model, the intent is that it is the same attribute (may be I am LDAP biased?).  My worry is case-sensitivity would lead to issues and confusion. 

Never-the-less, Eric makes a good point about client scripts having some difficulty since JSON is typically case-sensitive.

So the work-around would be that servers would always camel-case incoming names to create flexibility and auto-correct names.  However they would always be consistent when returning results.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Mark Diodati <[email-masked]>
Date: Fri, 7 Jun 2013 15:35:58 -0500

Hi Phil,

Thanks for fleshing this out! It makes good sense that the SP will serve
up case sensitive names to the consumer, but accept some case variation
from the consumer.

Mark

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]]
Sent: Friday, June 07, 2013 2:44 PM
To: Mark Diodati
Cc: Erik Wahlström; [email-masked]
Subject: Re: [scim] attribute name questions on

Mark,

Are you saying you want case-sensitive?  IOW   UserName <> Username <>
userName <> username

If case-sensitive on server-side, the concern would be a profile could end
up with different values for Username and username.

Yet, from an information model, the intent is that it is the same
attribute (may be I am LDAP biased?).  My worry is case-sensitivity would
lead to issues and confusion.

Never-the-less, Eric makes a good point about client scripts having some
difficulty since JSON is typically case-sensitive.

So the work-around would be that servers would always camel-case incoming
names to create flexibility and auto-correct names.  However they would
always be consistent when returning results.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-06-07, at 12:38 PM, Mark Diodati wrote:

> depending on your preferred language / json parser. An example in
> plain javascript.
>
> I'm not saying you shouldn't do more parsing then that on a scim
> resource, but I don't see that it's enough upside to allow it.
>
> / Erik
>
>
> secion 10.  Resource Schema when we talk about attributes.name.
> Currently description is only "The attribute's name.".
>>>

---

From: Erik Wahlström <[email-masked]>
Date: Tue, 11 Jun 2013 11:10:07 +0000

Hi,

It's certainly a valid point that we do not want to create two different objects for username and UserName. How about making it very obvious that the spec is case-sensitive and return a 400 bad request if someone sends Username instead of userName? That would solve the problem with duplicates and keep the spec strict and implementations more interoperable.

/ Erik

---

From: Phil Hunt <[email-masked]>
Date: Tue, 11 Jun 2013 07:24:28 -0700

I think that leads to a lot of practical interop problems. We can learn from ldap/x500 on this. Too strict and things break all the time. In this case, the intent is always clear so why throw errors?

Phil