[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Handle-info] Re: Permissions Not Implemented?



Hi Sam:

Didn't see your response (below) listed on the mail archive, so forwarding
here.

I updated the RFC update table at

    http://code.google.com/p/openhandle/wiki/HandleSpecification

to move these three elements back to the "Leave" column and updated the
comment.

> server administrator. There will also be other changes/extentions to the
> handle spec to support many new use of the handle system. Hopefully we will

Would be good to get a heads-up of those changes so that we can manage an
ongoing RFC/Code comparison and user expectations based on that.

Cheers,

Tony
 

On 17/3/08 15:24, "Sam X. Sun (gmail)" <sam.sun.xun@gmail.com> wrote:

> Just followed up with this thread... and want to point out that:
> 
> The permissions for PUBLIC_EXECUTE, ADMIN_EXECUTE will be necessary when we
> support web-service and grid applications, and will be implemented thereof.
> LIST_NA should be the permission for the namespace administrator, not the
> server administrator. There will also be other changes/extentions to the
> handle spec to support many new use of the handle system. Hopefully we will
> have these issues clearified when we do that.
> 
> Thanks,
> Sam
> 
> 
> ----- Original Message -----
> From: "Hammond, Tony" <t.hammond@nature.com>
> To: "Sean Reilly" <sreilly@cnri.reston.va.us>
> Cc: <handle-info@cnri.reston.va.us>
> Sent: Monday, February 11, 2008 1:25 PM
> Subject: Re: [Handle-info] Re: Permissions Not Implemented?
> 
> 
>> Thanks Sean for the confirmation (and explanation).
>> 
>> Might it not be appropriate now to consider issuing a revised RFC at some
>> point (hopefuly soon) to firm up the current position of the HS? These
>> diffs
>> (as well as the type diffs which I also questioned) could be taken care of
>> in some kind of 5-year overhaul of the RFC. (And note that some standards
>> e.g. NISO have a 5-year review.)
>> 
>> And another open question, which I hate to mention, but it's still open -
>> and therefore fair game, is about a native URI scheme for handle, or URN
>> namespace if that's preferred  - or both (there is a precedent, I think,
>> but
>> can't remember off the top of my head).
>> 
>> I know that a "doi:" registration is likely deferring to an eventual ISO
>> imprimatur on the DOI System, but not sure that that has any direct
>> bearing
>> on handle. I wonder if it might be appropriate to consider the bundling of
>> a
>> URI scheme specification (or URN) together with any revised RFC spec,
>> rather
>> than being undertaken as a separate business (which will only draw flak
>> and
>> grief and "woe is us"). Other protocols - notably HTTP (RC 2616) - are
>> responsible for declaring their own URI schemes. Seems to me this could be
>> the right opportunity to deftly tuck that away in some kind of appendix.
>> There has already been a relaxing of the URI registration stranglehold
>> (witness "info"). And may be better to get in before the "linked data"
>> wave
>> converges all to HTTP.
>> 
>> My clear preference would be a native URI scheme. URN is so yesterday. :)
>> 
>> Cheers,
>> 
>> Tony
>> 
>> 
>> 
>> On 11/2/08 16:58, "Sean Reilly" <sreilly@cnri.reston.va.us> wrote:
>> 
>>> 
>>> On Feb 9, 2008, at 1:37 PM, Hammond, Tony wrote:
>>>> Hi:
>>>> 
>>>> Just to note regarding this observation about HS permissions that I
>>>> am using
>>>> HS 6.2.3. (I tried downloading 6.2.5 but the file permissions are
>>>> all messed
>>>> up, though don't expect there to be any substantial change between
>>>> the two
>>>> minor code versions.)
>>>> 
>>>> Also, as noted in my reply to Giridhar [1] there are also
>>>> discrepancies in
>>>> the pre-defined HS_* types between the RFC and the Java distro.
>>>> 
>>>> Would be useful to get some comments here from the authors.
>>> 
>>> Hi Tony,
>>> 
>>> You are right that there is a difference between the RFC and the java
>>> implementation as regards the PUBLIC_EXECUTE, ADMIN_EXECUTE and
>>> LIST_NA permissions.  The *_EXECUTE permissions were originally
>>> placeholders for a feature that wasn't completely designed and, IMHO,
>>> probably never will be.
>>> 
>>> The LIST_NA permissions should have been left out because it is an
>>> attribute of the server administrator and is therefore set in the
>>> server configuration file - not any prefix or service handle.
>>> 
>>> Thanks,
>>> Sean
>>> 
>>> 
>> 
>> 
>> *****************************************************************************
>> ***
>> DISCLAIMER: This e-mail is confidential and should not be used by anyone
>> who is
>> not the original intended recipient. If you have received this e-mail in
>> error
>> please inform the sender and delete it from your mailbox or any other
>> storage
>> mechanism. Neither Macmillan Publishers Limited nor any of its agents
>> accept
>> liability for any statements made which are clearly the sender's own and
>> not
>> expressly made on behalf of Macmillan Publishers Limited or one of its
>> agents.
>> Please note that neither Macmillan Publishers Limited nor any of its
>> agents
>> accept any responsibility for viruses that may be contained in this e-mail
>> or
>> its attachments and it is your responsibility to scan the e-mail and
>> attachments (if any). No contracts may be concluded on behalf of Macmillan
>> Publishers Limited or its agents by means of e-mail communication.
>> Macmillan
>> Publishers Limited Registered in England and Wales with registered number
>> 785998
>> Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
>> *****************************************************************************
>> ***
>> 
>> 
>> _______________________________________________
>> Handle-Info mailing list
>> Handle-Info@cnri.reston.va.us
>> http://www.handle.net/mailman/listinfo/handle-info
>> 
> 


********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************


_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info