Subject: [scim] June 26th WG conf call agenda

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Mon, 24 Jun 2013 04:52:13 +0000

Hello everyone,

So far we have two agenda items for the June 26th meeting:

-Schema discussions
-Language tagging of values

The instructions to get on the meeting is listed below in case you missed the email that went to the list.

Cheers,
Morteza

---

**** You can forward this email invitation to attendees ****

Hello ,

Morteza Ansari changed the meeting information.

Topic: Bi-weekly SCIM WG
Date: Every 2 weeks on Wednesday, from Wednesday, June 26, 2013 to no end date
Time: 10:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
Meeting Number: 341 774 049
Meeting Password: (This meeting does not require a password.)

-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://go.webex.com/go/j.php?ED=151921872&UID=0&RT=MiM0
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: (This meeting does not require a password.)
4. Click "Join".
5. Follow the instructions that appear on your screen.

To view in other time zones or languages, please click the link:
https://go.webex.com/go/j.php?ED=151921872&UID=0&ORT=MiM0

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code.
US Toll free: 1-855-797-9485
US Toll: +1-415-655-0002
Global call-in numbers: https://go.webex.com/go/globalcallin.php?serviceType=MC&ED=151921872&tollFree=1
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf

Access code:341 774 049

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://go.webex.com/go/mc
2. On the left navigation bar, click "Support".

You can contact me at:
[email-masked]<mailto:[email-masked]>
1-408 566-5647

To update this meeting to your calendar program (for example Microsoft Outlook), click this link:
https://go.webex.com/go/j.php?ED=151921872&UID=0&ICS=UMI&LD=1&RD=2&ST=1&SHA2=AAAAAbbMkYcCapya/yraKkwwjGVjg18L/FhwVs9bOtE5VNyE&RT=MiM0

WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link:
https://go.webex.com/go/meetingcenter/mcsetup.php

The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://go.webex.com/go/systemdiagnosis.php.

http://www.webex.com<http://www.webex.com/>

CCP:+14156550002x341774049#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 24 Jun 2013 09:40:16 -0400

> the email that went to the list.

In case it helps anyone, attached is an ICS file for the dates up to
the Berlin IETF meeting (three calls).

Barry

---

From: Phil Hunt <[email-masked]>
Date: Mon, 24 Jun 2013 14:28:42 -0700

Please see attached PDF for Wednesday.  Note: Though I intend to publish the related draft to IETF soon, I'm still working on it (and have not published yet).  Still the issues in finishing it is part of the reason for raising the language issue.

Phil

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

On 2013-06-23, at 9:52 PM, Morteza Ansari (moransar) wrote:

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

---

From: Chris Phillips <[email-masked]>
Date: Wed, 26 Jun 2013 10:22:48 -0400

Hi Phil,

Thanks for the notes in advance of the call.  Here's a question that may be useful point to talk about and mull over:

I'm not very clear on the need of the provisioning API to be language aware more so than say something like an LDAP server is aware of it's clients language considerations.

I think this problem has been encountered before in the land of LDAP and covered well in RFC 4512, specifically section 2.5.2.1 where it talks about how to decorate(my word, not the spec. word) values with options of attributes.   This could be things like language or even preferred values, it's wide open really and could be used for lots of things like preferred value or even forced ordering.

Would it make more sense to model SCIMs interaction with  language and attributes to a pre-existing standard and just reference it rather than mint a new way?

This would make it quite easy to have SCIM data stores in LDAP and they should 'just work' since it's part of the LDAP spec to manage options — or at least make it easier to store things with less effort.

Chris.

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Monday, 24 June, 2013 5:28 PM
To: Morteza Ansari <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] June 26th WG conf call agenda

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

Hello everyone,

-Schema discussions

Cheers,
Morteza

---

Hello ,

Topic: Bi-weekly SCIM WG

Access code:341 774 049

You can contact me at:

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.
_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: Phil Hunt <[email-masked]>
Date: Wed, 26 Jun 2013 09:35:50 -0700

Chris,

Thanks. I'll respond on the call. I think 4512/LDAP is one possible model, but think it may actually be problematic given SCIM's lack of LDAP centricity so far.  IOW, if you had to support it, what's the easiest way to map it to your underlying persistence architecture (e.g. rdbms, nosql, ldap).

Another consequence is an impact on single vs. multi-valued data. Should data with multiple language values still be considered single-valued?  Do we need another base data type?

Phil

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

On 2013-06-26, at 7:22 AM, Chris Phillips wrote:

> From: Phil Hunt <[email-masked]>
> To: Morteza Ansari <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 26 Jun 2013 18:19:54 +0000

Another option is to just provide some guidance around a suggested way support localization when it is needed.  My concern is that few attributes will require localization, so I would be reluctant to make big changes to the schema to support this.  Here is an example of something that is similar to option 2, but uses a schema extension to provide the localized values.

{
  ...
  "client_name": "My Client",

  "urn:oauth:clientRegistration:1.0": {
    "client_name_i18n": [
      {
        "value": "Mi Cliente",
        "lang": "es_MX",
      },
      {
        "value": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
        "lang": "ja_JP"
      }
    ]
  }
}

Notice that "client_name" remains single valued and provides the client_name in the default locale.  The localized values are in a separate attribute in an extension as a multi-valued complex attribute.  Using a complex multi-valued attribute with a "lang" key allows any number of locales and variants that don't have to be registered a priori in the schema (this is a problem with the attribute name masking and extend value options).

Also, by utilizing an extension, this could be grafted onto core resources in addition to the extended resource OAuthClient example.  However, the extension is not entirely necessary for extended resources that would like to include client_name_i18n as a top-level attribute on the resource.

--Kelly

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, June 24, 2013 4:29 PM
To: Morteza Ansari
Cc: [email-masked]
Subject: Re: [scim] June 26th WG conf call agenda

Phil

@independentid

---

From: Phil Hunt <[email-masked]>
Date: Wed, 26 Jun 2013 13:53:35 -0700

I'm not sure how the extension would work…especially when you get into complexities like extension of an extension, etc.

How about that for any attribute values may be expressed in the following forms:

1.  Simple name-pair:

"name":"My Name"

2. Value-tagged

Single Value -   
  "name":{"value":"My Name"}
Multi Value - 
  "name":[{"value":"My Name"} , … ]

3. Value and Language

Single Value -
"name":{
  "value":"My Client",
  i8n:["en_US":My Client",
          "ja-Jpan-JP":"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" ]
 }

Multi Value -
"name":[
{
  "value":"My Client",
  "type":"home",
  i8n:["en_US":My Client",
          "ja-Jpan-JP":"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" ]
 },
  . . .
]

So, what this would mean is that in the core spec, any of the 3 formats may be used.  Parsers would need to know to look for a straight value or a "value" tag which means one more level.  If in the "value" structure they detect "i8n", then there is multi-lingual data present.

---> for a filter, could someone then say something like  name.i8n.ja-Jpan-JP="\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" ?

Note:  As with any attribute, SCIM server is not necessarily obliged to retain all data it is given. However the server should be able to successfully parse the information.

Phil

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

On 2013-06-26, at 11:19 AM, Kelly Grizzle wrote:

> Notice that “client_name” remains single valued and provides the client_name in the default locale.  The localized values are in a separate attribute in an extension as a multi-valued complex attribute.  Using a complex multi-valued attribute with a “lang” key allows any number of locales and variants that don’t have to be registered a priori in the schema (this is a problem with the attribute name masking and extend value options).
>

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 27 Jun 2013 17:00:34 +0000

Notes and recording link from the June 26th WG call.  Many thanks to Bjorn for volunteering to be note taker.

---
Attendees:
Morteza Ansari (host)
A. Paventhan
Alexandre Santos
Kelly Grizzle
Phil Hunt
Bjorn Aannestad
Tony Nadalin

Summary of Discussion:
Schema Topics (KGrizzle)
     Issue #38 "Clarify Schema Extension Model" was discussed
     Proposed solution is doc'd in the ticket
     The prosposed solution involves adding a /resourceTypes end point
support for extensions
     Next Step: Turn the proposal into a set of draft text for the spec,
ideally for the Berlin meeting
Language issues (PHunt)
     Introduced a not-yet-submitted OAuth proposal for using SCIM to
register OAuth clients
     Main question: How to represent language-variants of attribute
values in JSON?  Three options presented.
     Next Steps: Ask for input on the mailing list, esp. from
implementers who have these language requirements

---

Your recording is now available on the WebEx service site. Click the link below to play it:

https://go.webex.com/go/lsr.php?AT=pb&SP=MC&rID=5945262&rKey=19e66736ad9870cd

Bi-weekly SCIM WG-20130626 1707-1
Wednesday, June 26, 2013 10:07 am San Francisco Time
56 Minutes

---

From: Erik Wahlström <[email-masked]>
Date: Thu, 27 Jun 2013 18:44:06 +0000

Hi,

Sorry for missing yesterdays meeting, was stuck in another one.

In my opinion, extending extensions seems like a slippery road to go down. Extending a new Resource type would be fine in my book, but extending extension within a Resource sounds like it can become rather tricky. I would rather prefer to create a new extension of the original one was not enough.

+1 on keeping language as extensions like Kelly proposed when it's needed. Another example would be to add some language tag to the ServicePoviderConfig and use Accept-Language HTTP headers to get all the versions supported, but it does not feel like the way to go. It is a corner case, so lets use extensions for it.

/ Erik

On Jun 26, 2013, at 10:53 PM, Phil Hunt wrote:

1.  Simple name-pair:

"name":"My Name"

2. Value-tagged

Single Value -

3. Value and Language

Single Value -
"name":{
  "value":"My Client",
  i8n:["en_US":My Client",

Multi Value -
"name":[
{
  "value":"My Client",
  "type":"home",
  i8n:["en_US":My Client",

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

{
  ...

--Kelly

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, June 24, 2013 4:29 PM
To: Morteza Ansari
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [scim] June 26th WG conf call agenda

Phil

@independentid
www.independentid.com<http://www.independentid.com/>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 27 Jun 2013 11:52:42 -0700

I am ok to look at kelly's proposal but it looks a lot more complex than what i just sent. I would like to see more. 

I am not yet convinced bolt on language support is even possible.  It would be bad to force breaking changes further down the road if it can't be layered on. 

Phil