Hi Erik,
I just went over the changes to multiple resource profile and have the
following questions:
- Section 2.4.3, line 186: Should this say "The Context Handler
MUST construct ..."? i.e. it would have to in order to be consistent w
the other sections, since this is higher level and includes those
sections conceptually - lines 196-198.
- Section 2.4.3, lines 190-191: This says that the
<Attributes> elements in the generated Request must be in the
same order as what? The order of the <AttributesReference>
elements in the RequestReference? Assuming so, main question here is
whether there is any significance to this order. i.e. does it matter in
an ordinary request what order the Attributes elements, each with a
different Category come in?
- Section 2.4.3, lines 192-194: I am confused by this paragraph. It
says: "If ..., there MUST be exactly one Response ...". My impression
is that it is always true that there must be one Response for
everything in the original Request, and that if the original Request is
broken up into multiple individual Requests by the ContextHandler, that
then each of those individual Requests will produce one or more Results
and all the Results from all the individual Requests will be packaged
into one Response. It also seems to say this as an after thought on
line 198-199. It would probably be better, if that is what is intended
to state this at the beginning and not piece it together along the way.
- Finally, I have a question on correlation of Results to
RequestReferences. The RequestReference uses the xml:id as we all
agreed to identify each Attributes element involved with the
RequestReference. So, how now are we supposed to correlate the
Responses? This issue was discussed at length in Jan but seems to have
dropped out of the picture without any clear resolution. It would seem
possible with xml:id, that possibly each RequestReference could have
its own xml:id and that this xml:id could be put in the Result element
by the ContextHandler while it is constructing the Response.
Thanks,
Rich
Erik Rissanen wrote:
49AD05B2.1040907@axiomatics.com" type="cite">All,
I have posted new drafts of the core and the multiple resource profile.
See the change logs and tracked changes for details.
As far as I can tell, we don't have any open issues on the following
specs:
- Core
- Multiple resource
- Administration
- Privacy
- SAML
- Dsig
The hierarchical profile is being discussed currently and there was
discussion about improving the RBAC profile.
The proposed work on the RBAC profile seems in very early stages and
the issue (policies about management of roles) is a major topic, so I
propose that we don't bring this in 3.0.
So, could we agree on a feature freeze on the above mentioned profiles?
If so, all of the expect hierarchical are ready for review before going
to committee draft.
I also propose that if we don't get resolutions on the issues in the
hierarchical profile soon and it would appear that there are major
changes required, then we use the old version of that profile. However,
my understanding is that Rich has pretty much completed the work on
that. I haven't had the time to review it myself yet, but I will do so
now.
So, given the above, can we agree on the following?
- everybody reviews the above mentioned profiles
- We correct any mistakes
- I will fix the metadata, references, namespaces, etc,
- Go CD with the above
One final issue: we need to update the acknowledgements section of the
core. What goes in there? My name is not in there, and I would like to
include it. :-) I presume that we keep all the old names, right? John
Tolbert has requested to be added. Anybody else?
Best regards,
Erik
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|