Re: [Gen-art] Gen-art last call review of draft-ietf-scim-core-schema-17

Phil Hunt <> Thu, 07 May 2015 17:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4E5831A1A27 for <>; Thu, 7 May 2015 10:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HeCRMk37tUhB for <>; Thu, 7 May 2015 10:12:53 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 06CF31A6EF4 for <>; Thu, 7 May 2015 10:12:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1431018772; bh=FlZEqSNTIHnHdu2By1qD0ePbR0nr1dZQnxouQxey2C4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=ieEyIfY1ELHvE5jimaNGrl1nH+jxMXpWFqKoOCzlTZ4u027qo4Stfb6rnqDAOHg9ACKU7kar0FXXElWrYCTbBVH5lXZKUg907S8B7THvvFXHj/sUbggKkTlRRRj8lZeKUQMRM5a0HRqM0snBzwZafodFCvJ7mKT8khHY1Q7SbHvshVng4yg0VXfV4CjNMC7Cda3hzpCjjmIgWx1JCCxNlpMia42B1NGNPqjpSJ9ExjNaHL4HBkjn0eoBPUng3V63RB8kdNxsa6q4qoErVlu2STaSwtjPmT+obBNkiClLzaVtb+2qO2+42cvau2YDilJg+fCfmRjUu43hqwJH2GHMlA==
Received: from [] by with NNFMP; 07 May 2015 17:12:52 -0000
Received: from [] by with NNFMP; 07 May 2015 17:12:52 -0000
Received: from [] by with NNFMP; 07 May 2015 17:12:52 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: jYJbtl8VM1k9lQWKeFqf9w7.gOscae.mA59xhl7cRGae4gN dkqOCmvOuyDjoO4NNnO.lqCjk08jajFC7hFg5vVnX_3yF3qWNbfHZdbskl3P YiFT5GSMOsI_wBvd.4QaSUJ35AqZQ11iELAqdo._AlavCniEubSDNRv.8PRc zNbQyGcqqBRP6t01LGBP3wrhfiExPjjbzgieuorweoCyzK5n79imzqaE2ysI 2NEWMsKX8XadQ90hdrZmnVmOoeLD5D9HYgDl_n4oTC_zcQVp.AgWEb8uZyDm 2W97ZgqdLfadDSPsFQjK8sUIii8yZ8LRgq49WFBeoQoTCCJOfkfH3knCgnj3 kSDZG6HaBfO6ysrd748_CN4mjdAWSI4wK7kuzmbSF1X0Wjb6VCAKFNxUkuir EyY6G1AT4JavuijG.9xplMnCUruCraSbUwvDjNNOFs7zRaK.Ll.dOAdymY8q sfAXg8jlhUKi9dPf0SS8u3ww0c3DBCA.pfUB.NxZiFvbISldDvirrhtMD9yU i68rF1Voy2yej8KFquaTmCgMbQYAM6A--
X-Yahoo-SMTP: 5ZG1WouswBA_I3TiUVQ.pojpE5jY8w--
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Phil Hunt <>
In-Reply-To: <>
Date: Thu, 07 May 2015 10:12:49 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Elwyn Davies <>
X-Mailer: Apple Mail (2.2098)
Archived-At: <>
Cc: Leif Johansson <>, General area reviewing team <>,
Subject: Re: [Gen-art] Gen-art last call review of draft-ietf-scim-core-schema-17
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 May 2015 17:12:54 -0000


Thanks for this. I think these changes are reasonable and strike a better balance on standardized canonicalization vs. providing allowance for discretion.

I will add to the next update. 


> On May 7, 2015, at 10:02 AM, Elwyn Davies <> wrote:
> Hi, Phil.
> In my last email I realized I left in something about a further email I was going to send.  This was due to my thinking the telechat was sooner than it actually is.
> In creating this email, I realized that I wasn't sure whether the set of pre-defined sub-attributes in s2.4 (for the individual values of multi-valued complex-type attributes) should also apply to a single complex valued attribute.
> But the main point was about canonicalization.
> In the previous email, I had:
>>>> s7, canonicalValues:  The wording here
>>>>>         When
>>>>>         applicable service providers MUST specify the canonical types
>>>>>         specified in the core schema specification; e.g., "work",
>>>>>         "home".
>>>> seems to imply that the possible canonicalValues mentioned in the definitions of User, Group etc.
>>>> schemas earlier in the draft are actually normative minimum requirements that could, at least in
> >>> some cases, be extended.  The wording used in the earlier sections is rather less definitive and
>>>> appears to indicate that the suggested values are examples that a service provider might possible
> >>>want to replace if they considered alternative values better suited to their application, e.g.
>>>>>   userType
>>>>>      Used to identify the organization to user relationship. Typical
>>>>>      values used might be "Contractor", "Employee", "Intern", "Temp",
>>>>>      "External", and "Unknown" but any value may be used.
>>>> and
>>>>>   phoneNumbers
>>>>>      Phone numbers for the user.   ...  The "display" sub-attribute
>>>>>      MAY be used to return the canonicalized representation of the
>>>>>      phone number value.  The sub-attribute "type" often has typical
>>>>>      values of "work", "home", "mobile", "fax", "pager", and "other",
>>>>>      and MAY allow more types to be defined by the SCIM clients.
>>>> The wording used in the earlier sections seems to need 'tightening up'to make it clear what minimum set of canonicalValues is required for conformance, if indeed that is what is wanted.
>>> [PH] Agreed. Suggestion:
>>> A collection of suggested values for an attribute. For example often used with the “type” attribute to categorize a value such as “home” or “work”.  The service providerMAY choose to ignore values it does not support.
>> This helps.  The wording in s4.1.2 needs a little more work (see other email)....
> [So here it is]
> Is it intended that the various canonical values of the "type" sub-attribute for emails, etc., stated in s4.1.2 are normative requirements?
> It seems possible that there is a subtle difference between the "ims" and "photos" cases and the others:  For the "ims" and "photos" cases a different canonicalization is or might be needed for each possible type values, in which case the values would have to be tied down and be made normative, whereas the others are just a convenience for human users that would not generally be interpreted by machines with the same canonicalization whatever the value of "type".  OTOH, having standardized values helps the internationalization of the user interface in clients.
> If so I would suggest that these are rephrased to make it clear, for example, for emails (and similarly for phoneNumbers and addresses):
> OLD:
>      The "type" sub-attribute of contains values of "work", "home", and
>      "other", and MAY allow more types to be defined by the SCIM
>      clients.
> NEW:
>      The "type" sub-attribute is used to provide a classification
>      meaningful to the (human) user.  The user interface should
>      encourage the use of basic values of "work", "home",
>      and "other", and MAY allow additional type values to be used
>      at the discretion of the SCIM clients.
> For "ims" (and similarly for "photos"):
> OLD:
>      The "type"
>      attribute defines several "canonicalValues" to represent currently
>      popular IM services: "aim", "gtalk", "icq", "xmpp", "msn",
>      "skype", "qq", "yahoo", and "other".
> NEW:
>      The "type" sub-attribute SHOULD take one of the following
>      values: "aim", "gtalk", "icq", "xmpp", "msn", "skype", "qq",
>      "yahoo", and "other", representing currently popular IM services
>      at the time of writing. Service providers MAY add further values
>      if new IM services are introduced and MAY specify more detailed
>      canonicalization rules for each possible value.
> Regards,
> Elwyn