I believe the telechat review is scheduled for 14th. I think we should try and publish an updated version of both docs with all the known/agreed upon issues addressed by end of the week. Hopefully that would help the review and make it clear what exactly is the state of the doc.
Cheers, Morteza On 5/6/15, 9:42 AM, "Phil Hunt" <[email protected]> wrote: >Thanks Elwyn for your thorough review. Much appreciated. > >Yes I agree with your comment re internationalization. I would think a >best practice would be very helpful to move the industry. I guess as a >provisioning spec we are stuck having to deal with ossification since we >have to map legacy anglo structures. > >I plan to update very soon pending ok from Kathleen and the group on some >other issues. > >Thanks! > >Phil > >> On May 6, 2015, at 09:18, Elwyn Davies <[email protected]> wrote: >> >> Hi, Phil. >> >> Thanks for the response and the updated draft. >> >> I'll bite my tongue and defer to past history and the WG consensus on >>the internationalization issues. IMO this area is something that needs >>to be considered for other (new) specifications so that we don't remain >>ossified and adhering to a US/UK English paradigm that doesn't really >>fit other locales. But, as I said, this draft goes ahead as is on that >>front. >> >> There are some remaining minor comments on the updated draft inline >>below. If you don't get around to generating a new draft before the >>telechat, I'll send these as my telechat review. >> >> Regards, >> Elwyn >> >> >>> On 20/04/2015 19:30, Phil Hunt wrote: >>> Elwyn, >>> >>> Thanks for your careful and thorough review. I have included my >>>comments below. >>> >>> Note, if I have not commented below, please assume I agree with your >>>comment and will update the draft to include your feedback. >>> >>> Discussion inline below... >>> >>> Phil >>> >>> [email protected] >>> >>>> On Apr 17, 2015, at 2:26 PM, Elwyn Davies <[email protected]> >>>>wrote: >>>> >>>> I am the assigned Gen-ART reviewer for this draft. For background on >>>> Gen-ART, please see the FAQ at >>>> >>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>>> >>>> Please resolve these comments along with any other Last Call comments >>>> you may receive. >>>> >>>> Document: draft-ietf-scim-core-schema-17.txt >>>> Reviewer: Elwyn Davies >>>> Review Date: 2015/04/09 >>>> IETF LC End Date: 2015/04/20 >>>> IESG Telechat date: (if known) - >>>> >>>> Summary: Not ready. The 'major' issue identified is really political >>>>rather than strictly technical although the proposed syntax does limit >>>>the applicability (or at least the easy applicability) of the scheme. >>>>Making the schemas more aware of practice outside the basic English >>>>speaking world should be an aim of IETF work, IMO. The minor issues >>>>are mostly only just more than editorial nits - and there are quite a >>>>few of these also. >>>> >>>> Major issues: >>>> =========== >>>> s4.1.1, "name" attribute: The definition of this attribute is >>>>culturally insensitive. The >>>> collection of name sub-attribute terms are North >>>>American/UK/Aussie/NZ English -speaking biased. The authors might >>>>wish to consider >>>>http://www.w3.org/International/questions/qa-personal-names. >>> [PH] I am not sure I agree with your conclusion. SCIM is a >>>provisioning protocol and not a rendering protocol. SCIM is concerned >>>with conveying information between systems based on commonly used >>>fields. Further for formatted name, there is no restriction on how the >>>name may be structured. Essentially SCIM already follows the above >>>reference. Note that we don¹t use a regional identifier in name, but >>>rather have it as a separate attribute ³locale². This enables a UI to >>>render the name in the appropriate regional method. >>> >>> The WG did have several international participants and no issues were >>>raised. >>> >>> I believe that what is being reflected is that while database >>>structures and schemas tend to be ³western² oriented, there are well >>>trodden industry practices to map those fields to render user facing >>>material in the proper localized forms. >>> >>> In deference to your concern over the weekend, I re-raised the issue >>>with Oracle developers and have been informed that there has been an >>>internationalization review and the specification does not present any >>>problems for us as international implementers. >>> >>>> To a lesser extent this also applies to the definition of the >>>>addresses attribute in s4.1.2. The issue of the representation of >>>>postal addresses incorporated in I-Ds and RFCs in the xml2rfc schema >>>>has been debated at length on the rfc-interest mailing list. The new >>>>(v3) vocabulary replaces the specific sub-attributes with an ordered >>>>list of "postalLine" elements (see >>>>https://tools.ietf.org/html/draft-hoffman-xml2rfc-16#section-2.39). >>>>Further, the use of country codes in RFCs has been dropped some time >>>>ago. It might be better to represent the address in a less specific >>>>way and leave display up to user interfaces that can consider the >>>>relevant locale. My suggestion, FWIW, would be to have a country, >>>>possibly a code field plus an ordered array of postalLines that can >>>>contain any of the additional components and cater for any locale >>>>specific format. >>> [PH] The suggested workaround of following the format for XML2RFC >>>using an array of ³postalLine² values causes more problems in the >>>current SCIM model: >>> 1. SCIM does not support array references (e.g. postalLine/1, >>>postalLine/2). In some cases, the order of elements may not be >>>guaranteed by some impelementers (e.g. those building on top of LDAP) >>> 2. SCIM¹s objective is to provision. So the meaning associated with >>>the field must be well known to map it to the receivers data system. A >>>system line postalLine1, postalLine2 would require attribute parsing >>>which is substantially more complex and unreliable given the wide >>>variance. >>> 3. In practice, international data is collected through a >>>user-interface which then categorizes the input and maps them to the >>>appropriate attributes. If we introduce agnostic attribute naming in >>>the protocol (postalAddress1, 2 etc) we actually lose knowledge of what >>>the intended content is. This means that it becomes impractical to say >>>does postalAddress2 map to city, county, district, or mail stop of a >>>target system. >>> >>> IOW. In the XML2RFC, we depend on human editors to validate and align >>>the data. As a protocol we do not have this luxury. >> As per my comment at the top, I withdraw these comments and defer to >>the WG consensus. >>> >>> >>>> ====================================================== >>>> >>>> Minor issues: >>>> =========== >>>> Reference to SCIM Protocol document: At a bare minimum a normative >>>>reference to the SCIM protocol document (currently >>>>draft-ietf-scim-api-16) is needed in s1.2 where the protocol is >>>>referred to in the first two definitions. In my opinion, this >>>>document would be improved by the addition of a brief overview of the >>>>operation of the SCIM protocol and the implications for the design of >>>>the schema. For example, s2 talks about 'replacement of a resource': >>>> Knowing in advance that one of the operations anticipated in the >>>>protocol is replacement makes this clearer. >> My feeling is still that a brief overview of the SCIM protocol would >>help. Maybe something like inserted >> befoee the last para of s1: >> The SCIM Protocol is an application-level protocol for provisioning >>and managing identity data >> specified through the SCIM schemas. The protocol supports creation, >>modification, retrieval, >> and discovery of core identity resources such as Users and Groups, >>using a subset of the HTML >> methods (GET for retrieval of resources, POST for creation, searching >>and bulk modification, PUT for >> attribute replacement within resources, PATCH for partial update of >>attributes, and DELETE for >> removing resources). >> >>> No objection. There has been a practical problem that XML2RFC won¹t >>>let you reference a draft version that does not exist. In practice >>>we¹ve had to publish API 2 days after core-schema in order to allow the >>>validation to succeed. I will amend the document and leave notes for >>>the RFC editor to co-publish the specs since they reference each other. >> That will happen automatically - the documents form a RFC editor 'queue >>cluster' because of the references. This shouldn't be a big deal since >>they are going through IESG at the same time. >> >>>> s1.1, Use of OPTIONAL and REQUIRED: These terms are overloaded in >>>>this document. The majority of uses are not specifying features of >>>>the protocol as per RFC 2119 but indicating the necessity or otherwise >>>>of the presence of particular attributes in resource types. AFAICS >>>>the only RFC 2119 usages are one place in s2.2.7 for OPTIONAL and >>>>two adjacent places in s10.3.1 for REQUIRED . To avoid the >>>>overloading it would be easy to omit OPTIONAL and REQUIRED from the >>>>RFC 2119 list, use the alternative RFC 2119 terminology (MAY in s2.2.7 >>>>and MUST in s10.3.1) and provide a separate note on the usage of >>>>OPTIONAL and REQUIRED in s1.1. >>> [PH] In the context of a schema document, the use of OPTIONAL and >>>REQUIRED is equivalent to protocol normative language and was intended. >>> >>> Never-the-less, if you feel strongly, I can re-word to avoid RFC2119 >>>language entirely. >> This is a difficult one. When used as qualifiers for attributes they >>have implications for both implementers and end users. >> REQUIRED is not a big deal: Implementers MUST implement it and users >>MUST use it, so 2119 language is no problem. >> OPTIONAL is a bit more difficult. Does an implementer have to implement >>the OPTIONAL attribute? If the OPTIONAL attribute is implemented in a >>particular implementation, MUST the end user supply a value? And vice >>versa. >>>> s2.1, Syntax of attribute names: I am confused by the constraints >>>>suggested here. >>>> (1) "Attribute names SHOULD be camel-cased": AFAICS this has no >>>>impact on the specification or protocol. My guess is that the >>>>specification has adopted the convention normally used in JavaScript. >>>>This is merely a representation of the convention used in SCIM schemas >>>>and RFC 2119 language is inappropriate. I suggest replacing this with >>>> "This document uses the camel-casing convention for attribute names >>>>(e.g., "camelCase"). >>>> (2) "nameChar = "-" / "_" / DIGIT / ALPHA": Given the close >>>>association with JavaScript, it seems inappropriate to allow hyphen >>>>(-) as a character in attribute names as this is illegal in JavaScript. >>>> (3) The definition should say whether attribute names are case >>>>sensitive _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
