[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] SPML 2.0 Use Case doc, first draft...
Hot dog! You *have* been busy. I think
these use cases are a great basis for discussion. Just so you're not
surprised, here's what I intend to ask:
A-1: Why let the RA specify
PSO-ID? What if the specified value is invalid or non-unique? The
PSO-ID identifies the PSO to the PSP, so it must be valid and unique within the
(ID namespace managed by the) PSP.
Even if you let the RA *suggest* a PSO-ID, we
should specify that the PSP returns PSO-ID.
A-3: When you say
"attributes", do you mean specifically attributes or do you mean (more
generically) "content"?
I'm guessing the latter, since we discussed using
XPATH expressions to specify replacement of content in complex XML
objects.
A-5: Why let the RA generate
PSTD-ID? Username for an Account is fine; but I don't think that
username should be the PSTD-ID (e.g., because the account could be natively
renamed). The PSTD-ID should be opaque, unique, and meaningful only to the
PSP. The PSP should therefore generate it.
Even if you let an RA *suggest* PSTD-ID, we should
specify that the PSP returns the PSTD-ID.
A-6: More of A-5. PST may
generate native identifier(s), but PSP should define PSTD-ID.
A-7: Suggest using the word
"Implicit" rather than "Pass-through".
Gary
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]