Subject: Re: [scim] address.display versus address.formatted

From: David Crome <[email-masked]>
Date: Tue, 29 Mar 2016 13:06:30 +0200

For me it's not clear which sub-attributes the SCIM Address should
inherited from SCIM Multi-Valued Attribute. Currently we (
https://github.com/osiam/osiam) do not use the display sub-attribute, but
all other defined in https://tools.ietf.org/html/rfc7643#section-2.4. What
have others implemented?

2014-10-23 9:40 GMT+02:00 David Möbius <[email-masked]>:

> In our system the address attribute has a formatted value but no display.
> If you send a address with a display value it will be ignored.
>
> All other multi values have the display field, even if it contains just
> the normal value like the email address.
>
> David
>
> On 22.10.2014 18:04, Steve Moyer wrote:
>
>> I should also have noted that we haven't implemented all the attributes
>> (the ones we didn't need) yet.  We do however have 2.5m users with an
>> LDAP back-end currently available via both our v1 API (completely
>> non-standard) and through the SCIM interface.  We've got some additional
>> restrictions (on userName and externalId) that are specific to our
>> system but we're working towards being compliant with the specification
>> when it's ratified.
>>
>> If address.formatted and address.display are essentially the same thing,
>> I'd be happy to change my system to use display so that address is
>> consistent with all the other multi-valued attributes.  Can we drop
>> address.formatted altogether?
>>
>> Steve
>>
>> --
>>
>> “The mark of the immature man is that he wants to die nobly for a cause,
>> while the mark of the mature man is that he wants to live humbly for
>> one.” - Wilhelm Stekel
>>
>> ------------------------------------------------------------------------
>> *From: *"Shelley" <[email-masked]>
>> *To: *"Phil Hunt" <[email-masked]>
>> *Cc: *"Steve Moyer" <[email-masked]>, [email-masked]
>> *Sent: *Tuesday, October 21, 2014 3:45:56 PM
>> *Subject: *Re: [scim] address.display versus address.formatted
>>
>> Our implementation does the same thing, such that we ignore the address
>> "display" sub-attribute. Likewise, we do not support the "display"
>> attribute for several other multi-valued attributes since it seems to
>> provide no additional value beyond the "value" attribute:
>>
>>   * addresses
>>   * emails
>>   * phoneNumbers
>>   * photos
>>   * roles
>>
>> (We also currently ignore the ims, entitlements, and x509Certificates
>> attributes completely since we have no use cases for these, but would
>> likely ignore the "display" attribute for these attributes as well
>> should we add support for these attributes.)
>>
>> On Tue, Oct 21, 2014 at 11:16 AM, Phil Hunt <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     +1
>>
>>     Thanks Steve.  Curious to hear what others have implemented too.
>>
>>     Phil
>>
>>     @independentid
>>     www.independentid.com <http://www.independentid.com>
>>     [email-masked] <mailto:[email-masked]>
>>
>>
>>
>>     On Oct 21, 2014, at 8:53 AM, Steve Moyer <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>      > Are the address.display attribute (inherited from SCIM
>>     Multi-Valued Attribute) and the address.formatted attribute (part of
>>     the address definition) ambiguous?  Can anyone provide insight into
>>     how they're being used?  Our current implementation sets
>>     address.formatted and ignores address.display but I'm curious to
>>     know how others are populating these fields.
>>      >
>>      > Thanks,
>>      >
>>      > Steve
>>      >
>>      > --
>>      >
>>      > “The mark of the immature man is that he wants to die nobly for a
>>     cause, while the mark of the mature man is that he wants to live
>>     humbly for one.” - Wilhelm Stekel
>>      >
>>      > _______________________________________________
>>      > scim mailing list
>>      > [email-masked] <mailto:[email-masked]>
>>      > https://www.ietf.org/mailman/listinfo/scim
>>
>>     _______________________________________________
>>     scim mailing list
>>     [email-masked] <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/scim
>>
>>
>>
>>
>>
>> _______________________________________________
>> scim mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/scim
>>
>>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>

-- 
David Crome
Softwareentwicklung
tarent solutions GmbH

Telefon +49 (0) 30 138803-132
Telefax +49 (0) 30 56829495
[email-masked]

tarent solutions GmbH Niederlassung Berlin
Voltastraße 5, D-13355 Berlin • http://www.tarent.de/
Tel: +49 30 138803-0 • Fax: +49 30 56829495

Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-0 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer:
Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg