[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [regrep] Vote on version 2.03 - ACTION ITEM
Joel, The comments were meant for levity & perspective. That’s the problem with email, we can’t hear the
tone of voice or the facial expressions that go along with the comments. ;-} Anne A.
Fischer Drummond Group, Inc. 817.371.2367 -----Original
Message----- Anne, et al, Please be certain of the
following. While I have offered constructive criticism on more than one
occasion and have also cited specific issues with the specifications and
process, I greatly appreciate your efforts. I am unsure if you are
directing these comments personally toward me. If so, please tell
me. If they are meant in jest, great, I take them that way. My
comments are and always will be intended in a constructive manner. Joel -----Original
Message----- FYI - There are
33,344 words in the v2.03 specification.
12 grammatical/spelling errors were pointed out yesterday. That makes the spec 99.97% accurate in
regards to quality. I would say
that is good enough to vote on. Anne A.
Fischer Drummond Group, Inc. 817.371.2367 -----Original
Message----- farrukh, et al, with respect to making any changes to a specification after a
review of it has been done, we fundamentally disagree. is this farrukh';s
position or the position of the oasis ebxml registry tc? i believe very
strongly in quality, even at the cost of schedule. what you suggest
violates all of my (common) sensibility. this sets/continues a very bad
precedent. as i have in the past, i will continue to disagree with you
but will understand if the process moves on around me. in this case
however, i will not disagree and commit. i cannot vote yes for something
that is wrong. joel -----Original
Message----- Joel,
I was
specifically referring to the issue you raised regarding requiring digital
signatures on payloads. BTW the
rationale for this requirement was that since registries cannot afford to
verify integrity of submitted content and their source, a digital signature
would at least provide a link to the source of the content. Of course I
agree that typos and the "public
vs. private bug" must be fixed in 2.1. I do however disagree that a second
review cycle and vote should be necessary for fixing minor typos like this. I
think we can simply say we approve the specs with specific comments they want
to make sure are addresses. -- "Munter,
Joel D" wrote: Please see my recent response to Suresh. On the 1st two
security related issues highlighted below, I agree. However, I strongly
believe that the public vs. private bug (highlighted) below, as well as the
bunch of spelling and grammatical errors that I noted in my original post the
other day should be fixed prior to the release of v2.1. Even if this
means another review/approval cycle. Joel -----Original
Message----- Joel, V2.1
is intended to be a bug fix release and not for arbitrary changes to the spec.
We have required digital signatures on payloads since the earliest versions of
the specs. This was not objected to by anyone in V1.0 or V2.0. Making any
changes here would be major and I would advice strongly against it. --
"Munter,
Joel D" wrote: My primary argument is, "financial and technological
barriers to entry." Certificate acquisition and management are not
free and not trivial. From a practical point, I may choose to make some
things that I publish, purely public and dsig just simply is not
required. I want to be able to choose what I sign. imho Signing
entries should be optional. It has been suggested (by others) that the
first two might be reconsidered in the V3 timeframe.Joel -----Original Message----- Joel,Responses to your security related, "non-typo"
type of comments below.Regards,-Suresh -----Original Message----- <snip>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."
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC