Re: [scim] [Editorial Errata Reported] RFC7643 (6403)

Phil Hunt <phil.hunt@independentid.com> Thu, 25 February 2021 17:54 UTC

Return-Path: <phil.hunt@independentid.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C903A1D75 for <scim@ietfa.amsl.com>; Thu, 25 Feb 2021 09:54:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy_SZMIp9oL2 for <scim@ietfa.amsl.com>; Thu, 25 Feb 2021 09:54:01 -0800 (PST)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D270F3A1D74 for <scim@ietf.org>; Thu, 25 Feb 2021 09:54:01 -0800 (PST)
Received: by mail-pl1-x631.google.com with SMTP id d11so3607704plo.8 for <scim@ietf.org>; Thu, 25 Feb 2021 09:54:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RAG/RjCt++6P6Q45ZHM1nQLfjq/GvtfS453HXmIIhsA=; b=0AuLTSAe0DwrGSs1sWL1a1SlgFkJ7IrFs+MUKSVB+Mtt0lZa90vKbwPUox0Xg2X5hh IuQtF3392LcDqog5J2wUiPsPF9VKzrhNmi7WFc9d0Ee3D7gFzs8s+f5pnxKBbvKWLSsX t2ml8tJ2Jm7241+Pqpt2MecWRsy8z68v5Vx/vtHIc55UB/2ONI1sLBx5AEx6oJzAic2F RwUkjHkQY3iuT4brc+a0i8jWiBXHpmdBSNSf2CG87UdcIRYElffLj2nGAFmRc1rFLpsY 2u93gdZniPWsUBbmkEy9zWcss19b1mLGMrkTN0A+OSzHPS4GHFaoH/A31nX3D7WGcZKg xfVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RAG/RjCt++6P6Q45ZHM1nQLfjq/GvtfS453HXmIIhsA=; b=sBpp3YW1NZb+e8mhJS4uZ9PqHvpDV83KMcaZ4WnA4SefdYle3SfuBANRM52yAm03mp VW0cxL89Iynr4TQ1EG2RKRde9QmK3AkN1TY4FLDWi+jMNyfbbxcHbDd4RLSm/f51f8Sb +F02TLeFNxKrxuN1VC7e2oLdb5faOrC3HrTCPg5eAhXx6v1H1njAHPjx4m19Atq8iLXq CGaej4rtcud5JPPqyvsCDctXznL96jyAqdyx35J77kRi5qHYPvH4tLbZqke7qNLBxq4D kFGLDPx1iQnR09hwu79YCpeYP/eOmbIfCLtwPr8hfBPP3AMiiI3Mxw1XQqK59L6rYHnj uRjQ==
X-Gm-Message-State: AOAM533pl+8YeChCOCzer5p8NSw6SsK15+cer1bsurG/sOPg9pTG4f0g KZTPC20ODJdrAUACFZGqB8beEg==
X-Google-Smtp-Source: ABdhPJytTG1JK9G3OFmF2Uy/tawMpMx6Bp3jkV4IiYZfkh9J5gImEJytpULPexaq6nAVQSmOIZubtw==
X-Received: by 2002:a17:90a:de5:: with SMTP id 92mr4257083pjv.191.1614275641201; Thu, 25 Feb 2021 09:54:01 -0800 (PST)
Received: from node-1w7jr9qrfoxx92jd7rm298sd0.ipv6.telus.net (node-1w7jr9qrfoxx92jd7rm298sd0.ipv6.telus.net. [2001:569:7a71:1d00:65a6:806e:1b49:5294]) by smtp.gmail.com with ESMTPSA id nh6sm6344781pjb.21.2021.02.25.09.54.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Feb 2021 09:54:00 -0800 (PST)
From: Phil Hunt <phil.hunt@independentid.com>
Message-Id: <2C8FD6B7-9855-43B5-A2FE-D85910966970@independentid.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_15D17584-582A-44F7-90E6-7E8B715832BE"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Thu, 25 Feb 2021 09:53:59 -0800
In-Reply-To: <CALaySJLLWFhbh=S742ZHYGQG=dwu_qgnEf_1fq_n6g8HdaiwBQ@mail.gmail.com>
Cc: Andrew Webb <andrew.webb@outthink.io>, RFC Errata System <rfc-editor@rfc-editor.org>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, Murray Kucherawy <superuser@gmail.com>, Morteza Ansari <moransar@cisco.com>, Leif Johansson <leifj@sunet.se>, "scim@ietf.org" <scim@ietf.org>
To: Barry Leiba <barryleiba@computer.org>
References: <20210223111822.B884FF40765@rfc-editor.org> <F9D9A399-A585-4DD2-88F2-DE7EA1E72ACC@yahoo.com> <CALaySJKX5aqc2UfBa48PNkhOTrCL+Ft4_+hXZuYikBLOKJ2yww@mail.gmail.com> <LO3P123MB3372AE80FAEAC53D5A98EC49FB9E9@LO3P123MB3372.GBRP123.PROD.OUTLOOK.COM> <CALaySJLLWFhbh=S742ZHYGQG=dwu_qgnEf_1fq_n6g8HdaiwBQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/nKiaxUkWW9-L5KiUKLBOoA9GuPc>
Subject: Re: [scim] [Editorial Errata Reported] RFC7643 (6403)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Feb 2021 17:54:04 -0000

Regarding errata 6403…

EDIT - Editorial

While I agree for consistency that “RECOMMENDED" is not the best, I believe the group wanted “RECOMMENDED” to encourage more support for use. In particular it was probably bad to make it all caps because it is not normative in the protocol sense.

Related, the example schema on page 71 shows the attribute is optional (Required = false).  Also, the enterprise user schema which contains the “manager” attribute is optional in practical terms.

In practical terms, any deployer is free to make such attributes mandatory or not as long as they publish the deployed schema in the /Schemas endpoint.

I would recommend changing “RECOMMENDED” to “Recommended” as the use is not normative.

Phil Hunt
@independentid
phil.hunt@independentid.com




> On Feb 25, 2021, at 5:58 AM, Barry Leiba <barryleiba@computer.org> wrote:
> 
>> Re. my earlier errata for the same RFC:
>> https://www.rfc-editor.org/errata/eid6403 there was no feedback and
>> it's still unverified (as are a few others), so I wondered if anyone
>> was out there.  But I will take your non-rejection of it as
>> acceptance.
> 
> Unfortunately, we're not always good about handling errata reports,
> and we should do better.
> 
> Phil, errata report 6403 looks correct to me.  Will you take a look at
> it and comment, please?
> 
> Barry
> 
>> 
>> On another matter: I have questions about `userName` and its uniqueness constraint.  Where best to ask?  StackOverflow?
>> 
>> Thanks.
>> 
>> Yours,
>> Andrew
>> 
>> 
>> 
>> 
>> Andrew Webb
>> Senior Engineer (Architecture & Development)
>> OutThink
>> 
>> 
>> andrew.webb@outthink.io |
>> +44 203 432 4846 |
>> 35 New Broad Street, London, EC2M 1NH, United Kingdom
>> 
>> 
>> OutThink is the Highest Rated Security Awareness Solution
>> Reviews from your enterprise peers – verified by Gartner
>> Read our reviews or contribute a review today on Gartner Peer Insights
>> 
>> 
>> ________________________________
>> From: Barry Leiba <barryleiba@computer.org>
>> Sent: 23 February 2021 21:34
>> To: Phil Hunt <phil.hunt@yahoo.com>
>> Cc: RFC Errata System <rfc-editor@rfc-editor.org>; Kelly Grizzle <kelly.grizzle@sailpoint.com>; Erik Wahlström neXus <erik.wahlstrom@nexusgroup.com>; Chuck Mortimore <cmortimore@salesforce.com>; Murray Kucherawy <superuser@gmail.com>; Morteza Ansari <moransar@cisco.com>; Leif Johansson <leifj@sunet.se>; Andrew Webb <andrew.webb@outthink.io>; scim@ietf.org <scim@ietf.org>
>> Subject: Re: [Editorial Errata Reported] RFC7643 (6438)
>> 
>> Yes, Phil, and I already rejected the errata report a few hours ago.
>> 
>> Barry
>> 
>> On Tue, Feb 23, 2021 at 2:10 PM Phil Hunt <phil.hunt@yahoo.com> wrote:
>>> 
>>> I believe this is a technical issue within the RFC issue. Officially the .txt is considered normative.
>>> 
>>> Please correct me if I am wrong.
>>> 
>>> 
>>> Phil Hunt (RFC7643 editor)
>>> phil.hunt@yahoo.com
>>> 
>>> 
>>> 
>>>> On Feb 23, 2021, at 3:18 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>>>> 
>>>> The following errata report has been submitted for RFC7643,
>>>> "System for Cross-domain Identity Management: Core Schema".
>>>> 
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> https://www.rfc-editor.org/errata/eid6438
>>>> 
>>>> --------------------------------------
>>>> Type: Editorial
>>>> Reported by: Andrew Webb <andrew.webb@outthink.io>
>>>> 
>>>> Section: 3.1.
>>>> 
>>>> Original Text
>>>> -------------
>>>>    version  The version of the resource being returned.  This value
>>>>        must be the same as the entity-tag (ETag) HTTP response header
>>>>        (see Sections 2.1 and 2.3 of [RFC7232]).  This attribute has
>>>>        "caseExact" as "true".  Service provider support for this
>>>>        attribute is optional and subject to the service provider's
>>>>        support for versioning (see Section 3.14 of [RFC7644]).  If a
>>>>        service provider provides "version" (entity-tag) for a
>>>>        representation and the generation of that entity-tag does not
>>>>        satisfy all of the characteristics of a strong validator (see
>>>>        Section 2.1 of [RFC7232]), then the origin server MUST mark the
>>>>        "version" (entity-tag) as weak by prefixing its opaque value
>>>>        with "W/" (case sensitive).
>>>> 
>>>> Corrected Text
>>>> --------------
>>>>    version  The version of the resource being returned.  This value
>>>>        must be the same as the entity-tag (ETag) HTTP response header
>>>>        (see Sections 2.1 and 2.3 of [RFC7232]).  This attribute has
>>>>        "caseExact" as "true".  Service provider support for this
>>>>        attribute is optional and subject to the service provider's
>>>>        support for versioning (see Section 3.14 of [RFC7644]).  If a
>>>>        service provider provides "version" (entity-tag) for a
>>>>        representation and the generation of that entity-tag does not
>>>>        satisfy all of the characteristics of a strong validator (see
>>>>        Section 2.1 of [RFC7232]), then the origin server MUST mark the
>>>>        "version" (entity-tag) as weak by prefixing its opaque value
>>>>        with "W/" (case sensitive).
>>>> 
>>>> Notes
>>>> -----
>>>> In the original text, the hyperlinks applied to "2.1" and "2.3" incorrectly link to those sections in RFC 7643, whereas they should link to those sections in RFC 7232.
>>>> 
>>>> Instructions:
>>>> -------------
>>>> This erratum is currently posted as "Reported". If necessary, please
>>>> use "Reply All" to discuss whether it should be verified or
>>>> rejected. When a decision is reached, the verifying party
>>>> can log in to change the status and edit the report, if necessary.
>>>> 
>>>> --------------------------------------
>>>> RFC7643 (draft-ietf-scim-core-schema-22)
>>>> --------------------------------------
>>>> Title               : System for Cross-domain Identity Management: Core Schema
>>>> Publication Date    : September 2015
>>>> Author(s)           : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore
>>>> Category            : PROPOSED STANDARD
>>>> Source              : System for Cross-domain Identity Management
>>>> Area                : Applications and Real-Time
>>>> Stream              : IETF
>>>> Verifying Party     : IESG
>>>