OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [regrep] Folder proposal overview

+1 on leveraging XACML and minimal change to spec

<quote who="Farrukh Najmi">
> <from meeting note 5/13/04>
> Folder idea (carry over from F2F). Farrukh not present. Duane’s concern
> that it could violate the MVC and bring registry into UI.
> </from meeting note 5/13/04>
> I had explained this at the New Orleans f2f that everything I propose is
> part of Information Model (the M in MVC). There is no violation of MVC
> by introducing view into the specs.
> We are defining a registry and a repository. All repositories support a
> notion of files and folders as part of their model to facilitate
> structural organization of content (see nt:file and nt:folder in JSR 170
> for example). This has nothing to do with views (how the structure is
> displayed).
> No let us go back to the motivation of why I am proposing this
> enhancement in historical retrospective perspective...
> In version 2.5 we added an HTTP interface that allowed all
> RegistryObjects and RepositoryItems to be accessible via a URL based
> upon its id. The problem was that the URL was meaningless to the
> submitter (kind of like a KAVI URL).
> So next we introduced post 2.5 and approved the "User defined URL"
> feature. This feature augmented the HTTP interface by allowing a
> submitter to optionally provide one or more user defined URLs that were
> meaningful to the user. This was a major improvement.
> However we still have an issue that user-defined URLs have no access
> control. Anyone can assign any (potentially misleading) URL to objects
> they own. For example lets us say Duane is using the following URLs
> prefix for all hist objects:
> ..../userData/duane/....
> Now along comes Farrukh and submits some false information allegedly
> pertaining to Duane under the URL:
> ..../userData/duane/companyInfo/aboutDuanesCompany.html
> There is absolutely nothing that Duane can do since I published that URL
> on *MY* object. But the damage is done to Duane's stellar reputation.
> The File/Folder metaphor proposal augments the user-defined URLto allow
> Duane to protect his stellar reputation.
> The Registry has a userData folder as root of all userData. The folders
> access control allows anyone to create files and folders in it. Duane
> creates a folder named "duane" under it and sets its access control to
> only allow Duane and possible his dear wife and some choice friends to
> create files and folders under it. I simply will not be able to write my
> slanderous files under Duane's folder. Dang! ;-)
> How would this work? Quite simple really. We use some of our existing
> "few good primitives" and put them to work for this use case as follows...
> To create a Folder one creates a RegistryPackage.
> To assign access control to a folder access control one uses "reference
> access control" using XACML ACP that we already support. See a couple of
> examples attached. The examples have comments explaining things.
> To create a file within a folder one simply creates a RegistryObject
> (which could be a RegistryPackage / folder) and adds it as a member of
> the RegistryPackage for the folder. The file can have its own ACP. This
> is just like Unix file system permissions which is a tried and trusted
> model. BTW Unix filesystem is not violating MVC - is it?
> Finally, note that we do not have to introduce any new "Folder" or
> "File" type in RIM. In fact we do not have to change RIM at all!
> In summary, with little effort we provide a valuable enhancement to our
> repository feature.
> Does this explaination address some of the concerns and clear some
> misunderstandings?
> PS: My apologies for missing yesterday's meeting. My best friend's epic
> 2 month long wedding party had another significant event.
> --
> Regards,
> Farrukh
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.

Carl Mattocks

co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC
co-Chair OASIS Business Centric Methodology TC
v/f (usa) 908 322 8715
Semantically Smart Compendiums

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]