[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Handle-info] RFC Updates for Predefined Handle Types
Hi Sam:
Likewise another mail that didn't seem to make it to the mail archive.
I again updated the RFC update table at
http://code.google.com/p/openhandle/wiki/HandleSpecification
to move these two types back to the "Leave" column and updated the comment.
> The types listed in handle RFC should only cover those data types necessary
> to carry out the handle protocol operation, but not every types in the
> type-registry, i.e. types registered under the "0.type" prefix.
> Applications, as well as handle reference implementations, may register any
> data-types as they need under the "0.type" prefix, but unless they are
> considered necessary as part of the protocol operation, those data types
> shouldn't be put into the RFC.
Agreed. Would be useful if the code reflected that more explicitly.
Common.java has this table:
public static final byte STD_TYPES[][] = { STD_TYPE_URL,
STD_TYPE_EMAIL,
STD_TYPE_HSADMIN,
STD_TYPE_HSALIAS,
STD_TYPE_HSSITE,
STD_TYPE_HSSERV,
STD_TYPE_HSSECKEY,
STD_TYPE_HSPUBKEY,
STD_TYPE_HSDSAPUBKEY,
STD_TYPE_HSVALLIST,
STD_TYPE_HOSTNAME,
STD_TYPE_URN,
};
The tyoes *_URL, *_EMAIL, *_HOSTNAME and *_URN are not really "standard"
types as per the RFC, i.e. they're not necessary for handle operation. Well,
I guess they're standard in that they ship with the code but they're not
"system".
I know the actual system types are prefixed by HS_ but it still seems to be
a very close run thing as to which are "system" types and which are "user"
types. To lump them both in a single table under "standard" types could
potentially lead to confusion.
And I also know from your mail that HS_PRIMARY and HS_NA_DELEGATE should be
added to the table (and to the type registry), and from Sean's subsequent
mail that HS_DSAPUBKEY should be removed from here (and the type registry)
and HS_NAMESPACE added.
In all I make that 10 system types for the new RFC - the 7 per the current
RFC and 3 new types: HS_SECKEY, HS_PUBKEY, HS_NAMESPACE.
Cheers,
Tony
On 17/3/08 15:12, "Sam X. Sun (gmail)" <sam.sun.xun@gmail.com> wrote:
> Tony,
>
> HS_NA_DELEGATE is designed for handle prefex delegation, which will be
> implemented in the near future. HS_PRIMARY is the type reserved to support
> for multiple primary servers, which is not yet implemented by any reference
> implementation.
>
> The types listed in handle RFC should only cover those data types necessary
> to carry out the handle protocol operation, but not every types in the
> type-registry, i.e. types registered under the "0.type" prefix.
> Applications, as well as handle reference implementations, may register any
> data-types as they need under the "0.type" prefix, but unless they are
> considered necessary as part of the protocol operation, those data types
> shouldn't be put into the RFC.
>
>
> All the best,
> Sam
>
>
> ----- Original Message -----
> From: "Hammond, Tony" <t.hammond@nature.com>
> To: <handle-info@cnri.reston.va.us>
> Sent: Sunday, March 16, 2008 1:08 PM
> Subject: [Handle-info] RFC Updates for Predefined Handle Types
>
>
>> Hi:
>>
>> I know this is a pain in the backside but I was just following up my
>> earlier
>> questions [1] about predefined handle types. From that message it seems
>> that
>>
>> HS_NA_DELEGATE
>> HS_PRIMARY
>>
>> should be removed from the RFC as they don't occur in the code or type
>> registry (0.TYPE).
>>
>> Conversely
>>
>> HS_SECKEY
>> HS_PUBKEY
>>
>> look like they should be added to the RFC as they are both in the codebase
>> and type registry.
>>
>> The following type
>>
>> HS_DSAPUBKEY
>>
>> is listed in the codebase as being standard but is not listed in the type
>> registry. Could this be not a standard type at all but just a credential
>> type the same as
>>
>> HS_MAC
>> HS_SIGNED
>>
>> as it's also typed that way.
>>
>> As for
>>
>> HS_NAMESPACE
>>
>> I've really no idea. It doesn't look to be standard nor is it registered.
>>
>> I've added these types in a RFC update table [2] on the OpenHandle project
>> to make it easier to see at a glance updates required for the RFC.
>>
>> Sorry to be a pain but just seem to want it just so. :)
>>
>> Cheers,
>>
>> Tony
>>
>>
>> [1] http://www.handle.net/mail-archive/handle-info/msg00230.html
>> [2] http://code.google.com/p/openhandle/wiki/HandleSpecification
>>
>>
>> *****************************************************************************
>> ***
>> 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