[regrep - RIM draft 02 comment] Compendium

[Richard Martell <rmartell@galdosinc.com>]

Hi,


I've aggregated my comments regarding the latest RIM revision. Three
levels of severity are distinguished:

MAJOR    - significant impact, should be resolved
MINOR    - inconsistency that might hinder implementation or
            interoperability
ADVISORY - an editorial tweak, correction, or clarification

Again, no CRITICAL issues to report :-)


1 [MAJOR] RepositoryItem and ExtrinsicObject

   In section 1.5, replace occurrences of RegistryObject with
   ExtrinsicObject, since this is the actual type that serves as a proxy
   for repository items that reflect some specified content (media) type.

   Perhaps add a few words about using ExternalLink objects to reference
   items located in external repositories maintained by a third party.
   Or is this gambit frowned upon?


2 [MINOR] In 2.5.6 a lid is required, but not in the schema. Modify
   rim.xsd accordingly, and update the specification text such that
   within a publication request the submitter must specify either (i)
   a temporary (dummy) value that is subsequently replaced by the
   registry, or (ii) an absolute URI assigned by some other naming
   authority.

3 [MAJOR] In 2.5.9 the basic lifecycle of a registry object is ambiguous
   and should be clarified with a simple state diagram (also in terms of
   the canonical events listed in 7.1.2.1).

   e.g.

             approval          deprecated            deleted
   Submitted -------> Approved ---------> Deprecated ------> Withdrawn

   What triggers a state transition? Presumably a user can explicitly
   approve, deprecate, or delete objects. In which case the registry
   must not ignore the attribute in a request (which contravenes the spec
   directives).


4 [MINOR] In 2.7.1 the id and home attributes are specified for
   ObjectRef, but these are inherited from Identifiable and are therefore
   redundant here.


5 [ADVISORY] In 2.8.1 perhaps change values to type Set<LongName>
   instead of Bag, since duplicate values don't appear to be meaningful
   in this context.


6 [ADVISORY] In 2.8.3 append the following sentence: "The slotType
   attribute may also be used to indicate the type or value domain for
   the slot value(s)."


7 [MINOR] In 2.9.1 the default value for mimeType is
   "application/octet-stream". But what if there is no corresponding
   repository item? In this case, presumably the mimeType attribute
   is empty (i.e., there is no default value). Or would this absence be
   signalled by omitting ContentVersionInfo?


8 [MINOR] In 2.9.4 append the following sentence: "The value
   should be a registered MIME media type."


9 [MAJOR] In 3.6.1 (and elsewhere) ObjectRef is used as the type for
   many attributes. However, rim.xsd employs simple URIs (referenceURI)
   almost exclusively, rather than ObjectRefType (a complex type that
   maps to the ObjectRef class).

   The ObjectRef datatype in 2.2 has the same name as the RIM class. No
   packages are defined, so this is somewhat confusing. Perhaps rename
   the "ObjectRef" datatype in 2.2 so it doesn't clash with the class,
   or reuse one of the other simple URI-based types, like UUID.


10 [MINOR] In 4.2.4 the path attribute is required to be generated on
   retrieval. But according to the production rules in 4.2.5 this cannot
   be set if there is no value for the code attribute (which is
   optional). Suggest that the specification text be amended such that
   the path attribute is not required to be set, OR a looser directive
   to include the path only if codes are available.


11 [ADVISORY] In 5, "Responsible party information" might be a more
   apt designation, since we're concerned not just with the origin
   of an item but with identifying the owner and/or responsible party
   (person and/or organization--this may differ from the creator or
   source).

   "This chapter describes the classes that enable the description of
   the parties responsible for creating, publishing, or maintaining a
   RegistryObject or RepositoryItem."


12 [ADVISORY] In 5.3.5, the primaryContact for an Organization should
   reference a Person, as the contact need not be a registered User.


13 [ADVISORY] In 5.5.6, consider replacing stateOrProvince attribute
   with the more general attribute countrySubdivision (after ISO 3166-2).


14 [MINOR] In 5.6.5, shouldn't the number attribute at least be
   required? Currently _all_ attributes of TelephoneNumber are optional.


15 [ADVISORY] In 7.2.4, a default value for notificationInterval is
   specified but this does not appear in rim.xsd:

   <attribute name="notificationInterval" type="duration"
              use="optional" default="P1D" />

16 [ADVISORY] In 7.4.1, the type of the <any> attribute of
   QueryExpression should be anyType.


17 [ADVISORY] In 7.7.3, amend the last sentence as follows: "The
   registry MUST include Identifiable or RegistryObject instances as Set
   elements depending upon the notificationOption specified for the
   Subscription."


18 [MINOR] In 8.1, since a registry is itself a service it would be
   sensible for Registry to extend Service instead of RegistryObject.
   This would then permit bindings to be associated with affiliated
   registries. Otherwise, how are they located?


19 [MAJOR] Section 9 refers to XACML 1.0, but XACML 2.0 is the current
   standard. Should this section be updated accordingly?


20 [MINOR] Section 9 says much about policy _definition_ but rather
   little about policy _enforcement_. It seems to imply the existence of
   an embedded policy engine that evaluates relevant policies and renders
   appropriate access control decisions. That is, a registry is assumed
   to function as both a Policy Enforcement Point (PEP) _and_ a Policy
   Decision Point (PDP). If this is the case, it should be made explicit
   in the preamble for section 9.

   Alternatively, these functions could be distributed. For example, a
   registry could invoke a remote PDP using SAML (AuthzDecisionQuery) and
   enforce the resulting authorization decision.


-- 
Richard Martell         Public PGP key: <http://www.galdosinc.com/pgp/>
Galdos Systems, Inc.      tel: +1 604-484-2765  |  fax: +1 604-484-2755

Opinions, conclusions, recommendations, and other information presented
in this message are not given or necessarily endorsed by my employer or
firm. If the digital signature is invalid, I did not send this message.