Some
changes complete- see below.
Please provide opinions in regards to the “catalog”, “SAML”, and
“federated registeries” requested changes.
Thanks,
-Anne
-----Original
Message-----
From: Munter,
Joel D [mailto:joel.d.munter@intel.com]
Sent: June 12, 2002 5:45 PM
To: 'Oasis Registry TC'
Cc: Mikula, Norbert H
Subject: RE: [regrep] Vote on version
2.03 - ACTION ITEM
I cast
Intel's formal position on this TC specification vote as
"Abstain."
I note the
following ISSUES with the v2.03 ebRS. I mean the following comment in
only a constructive manner. Can authors and editors please run a
spell checker on these specifications prior to calling for a vote against
them. Compiling these took <1 hour. Not correcting them
continues to support the "less than able to quality" assertion that I have
made previously.
Appendix
A: the references to the WSDL files now be against the v2.1 files:
i.e.,
http://www.oasis-open.org/committees/regrep/documents/2.1/services/Registry.wsdl and
http://www.oasis-open.org/committees/regrep/documents/2.1/services/RegistrySOAPBinding.wsdl,
respectively
[aaf]: This was purposely left to be changed
upon approval of v2.1. It
will be updated after the vote.
line
3696:3697: I still believe that this specification should NOT mandate digital
signature for all content per the statement "The
Registry Client has to sign the contents before submission - otherwise the
content will be rejected."
line
3733:3734: I have the same objection to mandating digital signatures on
payloads per the text "This
packaging assumes that the payload is always signed."
[aaf]:
The previous two issues are v3.0 issues and are not appropriate changes for
v2.1
line
3876:3877: Should the second occurrence of public key in the following
sentence, "To
validate a signature, the recipient of the signature needs the public key
corresponding to the signer's public key.," actually be private
key? If not then something else seems very awkward about this
sentence.
[aaf]:
“signer’s public key” changed to “signer’s private key” The use of “public” was a
technical inaccuracy.
line 3916:
"privelege" should be "privilege"
[aaf]: Done
line 3933:
"someRegistry" should be "some Registry"
[aaf]: Done
line 4041:
"implementors" should be "implementers"
[aaf]: Done
line 4143:
"catalogs" should be "catalog" [aaf] Disagree. The sentence
is:
“The Registry SQL query capability supports the ability to
search for content based not only on metadata that catalogs the content but
also the data contained within the content itself.”
The recommended change is from “catalogs”
to “catalog”, however, I think this depends on whether you read “metadata” as
being singular or plural. I
checked Webster’s and the plural of data is data. Opinions?
Would adding a comma after each use
of “content” help to make the
sentence more readable? Would it
be grammatically correct?
line 4218:
"specificiation" should be "specification"
[aaf]: Done
line 4279:
"privilges" should be "privileges"
[aaf]: Done
line 4376:
"maximuminter-operability" should be "maximum
interoperability" [aaf]:
Done
line 4252:
SAML is mentioned but is not listed as a reference in Section
10 [aaf]: This is in section
F.1 Security Concerns -#4. Since
this is in an appendix, detailed information is not
required.
line 4253:
"releveant" should be
"relevant" [aaf]:
Done
line 4254:
"federated registries" is mentioned here but has never been defined,
described, or mentioned anywhere else
[aaf]: This is in section F.1 Security Concerns -#4a. Since this is in an appendix, detailed
information is not required.
line 4521:
"implementors" should be "implementers"
[aaf]: Done
Joel
-----Original
Message-----
From:
Breininger, Kathryn R [mailto:kathryn.r.breininger@boeing.com]
Sent: Tuesday, June 11, 2002 8:02
AM
To: 'ebXML
Regrep'
Subject: [regrep]
Vote on version 2.03 - ACTION ITEM
Importance: High
TC,
Attached is
the final version of the RS v2.03 for your review and vote. Please
submit your vote for approval, or disapproval by EOB June 17th. If
approved, this will be posted on our Registry TC as a TC approved document,
and will be renamed as v2.1 as noted by Anne below. We will also have an
agenda item during our telecon to discuss this.
Kathryn
-----Original
Message-----
From: Anne
Fischer [mailto:anne@drummondgroup.com]
Sent: Monday, June 10, 2002 4:00
PM
To: Regrep
Subject: [regrep] ebRS
v2.03
All,
Here is the
final version - currently labled ebRS v2.03. Once again, two copies..."ebRS v2.03
changes in view" and "ebRS v2.03 changes NOT in view".
Upon
approval by the TC, this version will be renamed v2.1.
-Anne
Fischer
Listed
below are the changes in ebRS v2.03:
- lines
3608, 3609, 3617, 3627: added urn:uuid prefix in id attribute in section 8.4.2
example
- lines
692, 969, 1010, 1038, 1069: correct spelling of
"Uavailable"
- line
1000: change "updated" to "approved"
- line
1028: change "updated" to "deprecated"
- lines
1148, 1149: change "is done via contentURI as explained in Section 8.4" to "is
accomplished using the technique explained in Section 8.4"
- lines
1150, 1151: Take out "the whole hierarchy of"?
- lines
2162, 2394, 2614; In order to be consistent with the rest of the
spec keep fonts for warnings Italic, but don't Bold
them
- line
2989: replace "If not, raise exception: object attribute
error" with "If not, raise exception: registry object
attribute error"
- line
3074: insert a new numbered paragraph after line 3074
For every
EmailAddressFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the EmailAddress UML class
defined in [ebRIM]. If not, raise exception: email address attribute
error. The EmailAddressFilter returns a set of identifiers for
EmailAddress instances whose attribute values evaluate to True for the Clause
predicate.
------Changes in Section
8.4.2---------------------
-Delete
lines containing "Content-Transfer-Encoding" in example.
-line 3583:
Replace "CPP" with "Collaboration Protocol Profile"
-bullet @
line 3576: Replace: "... as the value of the Content-ID header field for the
mime-part that contains ..."
With:
"... as the value of the
Content-ID header parameter for the mime multipart that contains...
"
-bullet @
line 3578 Replace: "In case of [ebMS] transport, use the ID for each
RegistryObject instance that describes the repository item in the Reference
element for that object in the Manifest element of the
ebXMLHeader."
With: "In
case of [ebMS] transport, use the ID of the ExtrinsicObject instance in the
Reference element for that object in the Manifest element of the
ebXMLHeader."
-Added at
the end of the first paragraph of section 8.4.2: "Note that the boundary parameter in
the Content-Type headers in the example below are meant to be illustrative not
prescriptive."
-Replaced
example in 8.4.2
-------------Changes
in Section 9.2.2-----------
-Bullet @
line 3694 Replace: "The second through nth body part must be the
content."
With: "The
second body part must be the content."
-Line 3695
Replace: "The packaging of the payload signature with one payload is as
follows:"
With: "The
packaging of the payload signature with two payload is as shown in example in
<cross reference to 8.4.2 make sure it is
hyper-linked>"
-Example at
3697-3792: Removed entirely since it is replaced by a example in
8.4.2.
-Line
3804-3805 Replace: "The packaging of the ds:Signature element in the SOAP header field is shown below."
With: "The
packaging of the ds:Signature element
in the SOAP header field
is shown in <cross reference to 8.4.2 make sure it is
hyper-linked>."
-Example at
3806-3828: Removed entirely since it is replaced by a example in
8.4.2.
------Section
9.3-------
-Line 3793:
After the 1st sentence "Message headers can be signed and are
referred to as a header signature." , add the following:
"When a
request is sent by a Registered User, the Registration Authority may use the
pre-established contract or a default policy to determine whether the response
contains a header signature. .
When a request is sent by a Registery Guest, the Registration Authority
may use a default policy to determine whether the response contains a header
signature."
-Begin new
paragraph with "This section specifies the requirements for generation, ....."