[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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/RegistrySOAPBinding.wsdl, respectively
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."
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.
line 3916:
"privelege" should be "privilege"
line 3933:
"someRegistry" should be "some Registry"
line 4041:
"implementors" should be "implementers"
line 4143:
"catalogs" should be "catalog"
line 4218:
"specificiation" should be "specification"
line 4279:
"privilges" should be "privileges"
line 4376:
"maximuminter-operability" should be "maximum
interoperability"
line 4252:
SAML is mentioned but is not listed as a reference in Section
10
line 4253:
"releveant"
should be "relevant"
line 4254: "federated registries" is mentioned here
but has never been defined, described, or mentioned anywhere
else
line 4521:
"implementors" should be
"implementers" 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, ....." |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC