"REGISTRY" back-end for profile info

[Joseph Calzaretta]

I apologize if this is received multiple times... krbdev at mit.edu is not 
liking me, I think due to my mail program sending messages in html 
format.  The following is something I wrote to which Jeff Altman has 
already replied.  I am sending it here again (hopefully in plain text) for 
completeness:

At 12:14 PM 11/22/2005, Jeffrey Altman wrote:
>This is order-dependent:
>
>[capaths]
>         RAEBURN.ORG = {
>         ATHENA.MIT.EDU = .
>              ANDREW.CMU.EDU = DEMENTIA.ORG
>                 DEMENTIA.ORG = ATHENA.MIT.EDU
>         GRAND.CENTRAL.ORG = ATHENA.MIT.EDU
>                 GRAND.CENTRAL.ORG = DEMENTIA.ORG
>         OPENAFS.ORG = ATHENA.MIT.EDU
>                 OPENAFS.ORG = DEMENTIA.ORG
>         SECURE-ENDPOINTS.COM = ATHENA.MIT.EDU
>                 SECURE-ENDPOINTS.COM = DEMENTIA.ORG
>         WINDOWS.SECURE-ENDPOINTS.COM = ATHENA.MIT.EDU
>                 WINDOWS.SECURE-ENDPOINTS.COM = DEMENTIA.ORG
>                 WINDOWS.SECURE-ENDPOINTS.COM = SECURE-ENDPOINTS.COM
>         }
>
>I would want to store [capaths] RAEBURN.ORG as REG_MULTI_SZ with the 
>order-dependent information inside.

Does this mean that capaths/RAEBURN.ORG should be a key with seven 
REG_MULTI_SZ values under it:
value: "ANDREW.CMU.EDU"                 data: "ATHENA.MIT.EDU"*
value: "ATHENA.MIT.EDU"                 data: "."*
value: "DEMENTIA.ORG"                           data: "ATHENA.MIT.EDU"*
value: "GRAND.CENTRAL.ORG"                      data: 
"ATHENA.MIT.EDU";"DEMENTIA.ORG"
value: "OPENAFS.ORG"                            data: 
"ATHENA.MIT.EDU";"DEMENTIA.ORG"
value: "SECURE-ENDPOINTS.COM"           data: "ATHENA.MIT.EDU";"DEMENTIA.ORG"
value: "WINDOWS.SECURE-ENDPOINTS.COM"   data: 
"ATHENA.MIT.EDU";"DEMENTIA.ORG";"SECURE-ENDPOINTS.COM"
(*single-valued entries could be stored as REG_SZ)

Or, are you saying that the top-level ordering is also important (e.g., 
capaths/RAEBURN.ORG/ATHENA.MIT.EDU/* is strictly before 
capaths/RAEBURN.ORG/ANDREW.CMU.EDU/*... notice their order in my example 
above)?  If it's this latter case, maybe we should talk about how to 
preserve the ordering without storing tree structure in a single 
REG_MULTI_SZ (for example, maybe keys named something like 
001_ATHENA.MIT.EDU, 002_ANDREW.CMU.EDU).

>and so is:
>
>[libdefaults]
>         default_tgs_enctypes = arcfour-hmac-md5 aes256-cts-hmac-sha1-96 
> aes128-cts-hmac-sha1-96 des3-cbc-sha1 des-cbc-crc des-cbc-md5 des-cbc-md4
>
>I would want to store [libdefaults] default_tgs_enctypes as REG_MULTI_SZ 
>with the order-dependent information inside.

Here, I'd think that for maximum portability that 
libdefaults/default_tgs_enctypes would just be a single REG_SZ value of 
"arcfour-hmac-md5 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 
des3-cbc-sha1 des-cbc-crc des-cbc-md5 des-cbc-md4", instead of a 
REG_MULTI_SZ split at all the enctypes.  Otherwise, I'm not sure how to 
distinguish it from something like:

>[libdefaults]
>         default_tgs_enctypes = arcfour-hmac-md5
>         default_tgs_enctypes = aes256-cts-hmac-sha1-96
>...
>         default_tgs_enctypes = des-cbc-md5
>         default_tgs_enctypes = des-cbc-md4

More generally, I'm not sure how "foo = bar baz" would be distinguished 
from "foo = bar \n foo = baz" in such a scheme.  If they are supposed to be 
the same (I can see a certain beauty in that) the current profile library 
API doesn't work that way.

What do you think?

--Joe