desk lamps

[Martin W Sachs <mwsachs@us.ibm.com>]

Henry suggested that I post my reply to him (with apologies to ebXML).

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 01/03/2001
08:36 AM ---------------------------

Martin W Sachs
01/02/2001 05:47 PM

To:   Henry Lowe <hlowe@omg.org>
cc:
From: Martin W Sachs/Watson/IBM@IBMUS
Subject:  desk lamps  (Document link: Martin W. Sachs)

Henry,

I'm with you on bricks and mortar.  Both my wife and I much prefer to "feel
the merchandise", she especially with books.  Of course at work, it's a
different matter since we place our own book orders with CBMSI and much of
our office supplies stock room has been replaced by a web site belonging to
a Very Large bricks and mortar chain. We use OBI to place orders with them
directly from our desks. I won't mention the chain's name but it has a
category code of "fasteners" :-)

I left out a point not germane to my original comment.  After I turned up
only clamps in my quest for a lamp, the purchasing department help desk
suggested that I look it up in my secretary's paper catalog.  I did and
discovered that the lamp I wanted has "incandescent" in its name.
Searching on "incandescent" (I don't think this is a substring of something
longer) turned up the lamp and I was able to order from the shopping basket
instead of filling out the form manually.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Henry Lowe <hlowe@omg.org> on 01/02/2001 05:05:46 PM

To:   Ebxml Transport <ebxml-transport@lists.ebxml.org>
cc:   "'Krishna Sankar'" <ksankar@cisco.com>
Subject:  RE: Registry Security Spec Version 003



I agree with Marty on the API.

Best regards,
Henry

PS: Hey, Marty, next time you're in Boston, I'll take you
to a Bricks-and-Mortar store that has more desk lamps than
you can shake a stick at -- you can touch and turn on and
return if necessary.  Oops, shouldn't say this on an ebXML
list ;-)
--------------------------------------------
At 08:02 PM 12/29/2000 -0500, Martin W Sachs wrote:
>
>David,
>
>I think that we are in agreement with "API" question but  just to be sure:
>
>We cannot enforce that implementers provide a rich API but we can
certainly
>encourage it by completing and publishing the service interface
>specification even if it is (and probably should be) non-normative.  The
>more non-normative discussion of possibilities there is in a
specification,
>the more likely that implementers will take the hint.
>
>This isn't only a question of implementer business decisions.  In many
>cases, I suspect that the problem is that the people doing the design and
>coding simply don't have a sufficiently broad and deep understanding of
the
>issues.  Lots of non-normative discussion can do a lot of educating.
>
>I recently tried to buy a desk lamp from a web service.  I searched their
>catalog for lamps and got a couple of hundred hits on clipboards and paper
>clips which obscured my lamp.  The reason turned out to be that the
catalog
>was giving me clamps in addition to lamps.  In that catalogue, "clamp" is
a
>category code which includes paperclips and clipboards. That's a case of
>someone not knowing the difference between searching on text strings and
>searching on words.  The more discussion we include, the more we can help
>to avoid such errors.
>
>Regards,
>Marty
>
>
****************************************************************************

>*********
>
>Martin W. Sachs
>IBM T. J. Watson Research Center
>P. O. B. 704
>Yorktown Hts, NY 10598
>914-784-7287;  IBM tie line 863-7287
>Notes address:  Martin W Sachs/Watson/IBM
>Internet address:  mwsachs @ us.ibm.com
>
****************************************************************************

>*********
>
>
>
>"Burdett, David" <david.burdett@commerceone.com> on 12/27/2000 03:40:26 PM
>
>To:   "'Krishna Sankar'" <ksankar@cisco.com>,
ebxml-regrep@lists.ebxml.org,
>      Ebxml Transport <ebxml-transport@lists.ebxml.org>, Ebxml-Ta-Security
>      <ebxml-ta-security@lists.ebxml.org>
>cc:
>Subject:  RE: Registry Security Spec Version 003
>
>
>
>>>>if there is only an anemic MAY, then all applications which use the TRP
>would have to specify alternate ways (for signature and encryption) as
>well.<<<
>
>I disagree. If the specification provides for a wire format that meets all
>the signature and encryption requirements of an application then there
>should be no reason why an application should not be able to use it, if
>they
>want to. If the software that an implementer has chosen doesn't allow it
>then it is the implementers problem for choosing the wrong software.
>
>IMO, I think we need to encourage the availability of software that
>provides
>a rich inteface to high level applications so that they can examine and
>process any data in an ebXML message **without requiring all solutions
>provide it**. For one thing you can't make software developers implement a
>rich API if they don't want to.
>
>However you can let software developers create solutions that meet
>customers
>needs. So if customers need access to the inner details of an ebXML
message
>then they will demand, and solution providers will presumably develop,
>solutions that meet that need. Similarly, if there is a demand, solutions
>that hide all the lower level details from the application will be
>developed.
>
>Once we do get the infamous Service Interface Specification developed then
>software vendors will be able to claim compliance with it and therefore
>provide the richer functionality you seek.
>
>Either way I honestly don't see how the specification can mandate the use
>of
>an API for the software, you just need to make sure that the specification
>encourages it but doesn't prevent it.
>
>Cheers !!
>
>David
>
>-----Original Message-----
>From: Krishna Sankar [mailto:ksankar@cisco.com]
>Sent: Wednesday, December 27, 2000 11:46 AM
>To: Burdett, David; ebxml-regrep@lists.ebxml.org; Ebxml Transport;
>Ebxml-Ta-Security
>Subject: RE: Registry Security Spec Version 003
>
>
>David,
>
>     Sorry David, if there is only an anemic MAY, then all applications
>which
>use the TRP would have to specify alternate ways (for signature and
>encryption) as well. Which is fine, so long as this is what the TRP specs
>says. But I would rather see a crisp specification which deals with what
>things would be done rather than possibilities.
>
>     Remember, we are talking about what and not how and when.
>
>     cheers
>
>> -----Original Message-----
>> From: Burdett, David [mailto:david.burdett@commerceone.com]
>> Sent: Wednesday, December 27, 2000 11:30 AM
>> To: 'Krishna Sankar'; ebxml-regrep@lists.ebxml.org; Ebxml Transport;
>> Ebxml-Ta-Security
>> Subject: RE: Registry Security Spec Version 003
>>
>>
>> I really think we are debating specification vs implementation.
>> You say that
>> SSL stips of the signature so that you can't see it. I haven't used SSL
>> myself, but I guess what you are actually saying is that SSL
>> implementations
>> strip of the signature and do not pass it to a higher level app.
>> Or does the
>> SSL **spec** require that signatures are stripped. I could imagine that
a
>> particular SSL implementation could make the signature available
>> if this was
>> important.
>>
>> What I think you are looking for in the ebXML TRP specs is
>> wording along the
>> following lines ...
>>
>> "Any or all of the data contained in the data communication protocol,
>MIME
>> envelopes and the ebXML Header Document, MAY be made available by the
>> Message Service Handler to an application or other process that is
>> processing the message. How this is done is implementation dependent
>> although ebXML Service Interface specification (to be developed)
>> provides a
>> non-normative design for how this may be done."
>>
>> David
>>
>> -----Original Message-----
>> From: Krishna Sankar [mailto:ksankar@cisco.com]
>> Sent: Wednesday, December 27, 2000 10:21 AM
>> To: Burdett, David; ebxml-regrep@lists.ebxml.org; Ebxml Transport;
>> Ebxml-Ta-Security
>> Subject: RE: Registry Security Spec Version 003
>>
>>
>> David,
>>
>>    Thanks for the e-mail. My comments are embedded.
>>
>> cheers
>>
>> > -----Original Message-----
>> > From: Burdett, David [mailto:david.burdett@commerceone.com]
>> <snip ../>
>> >
>> > The answer to this question depends on whether you are defining:
>> > a) a wire specification with a description of the behavior of
>> the software
>> > at each end, or
>> > b) a software solution that implements the specification defined in a)
>> >
>>
>> Yep, we are doing a wire specification. No problems here.
>>
>> > I think we are doing the former - the wire specification. More
>> > specifically
>> > we are saying the following:
>> > 1) You can have a XML Dsig compliant signature in the ebXML
>> > header which can
>> > potentially sign anything, and
>> > 2) The MIME part that is the payload may be digitally signed
>> > using, S/MIME,
>> > PGP/MIME or XML Dsig.
>> >
>> > However whether or not software that supports the ebXML specification
>is
>> > able to sign a payload really is an implementation decision of
>> > the software
>> > designer.
>> >
>>
>> David, you are addressing specification Vs implementation. I am not even
>> talking about implementation. If the software does not implement
security
>> stuff, then that particular installation will not have the capability.
>>
>> The question is whether the *specification* says the TRP is a black box
>or
>> not. It is a question of visibility to the upper layers - an
>> architectural/specification issue. Pl read on.
>>
>> > So to answer your question ... "Is the TRP going to be a black box
with
>> > regard to applications or will it "communicate" with the layers
>> > above ?" The
>> > real answer is it depends on how you build your solution or the
>> > features of
>> > the ebXML solution you buy.
>>
>> I disagree. If the specification leaves the architecture issues to the
>> implementer then we are asking for trouble ! For the lack of better
words
>> "communicate with the layers above" is *not* an implementation issue.
>>
>> Remember my question is not whether it is *available* or not, but
whether
>> there is an interface from the TRP layer to the upper application layer.
>> This need not be APIs or services, could be just elements in the XML -
>for
>> example if the signature is OK, the TRP puts an element
>> <SignatureVerified>Yes</SignatureVerified> in the header for the
>> application
>> to read - This is just an example.
>>
>> The visibility example can be best amplified by SSL. Even though SSL
does
>> encryption et al, the application cannot get to the signatures or the
>> encrypted payload. So even if the transport layer (actually the message
>> layer to be politically correct) uses SSL, the application still has to
>> specify how to sign a payload, how to encrypt it etc.
>>
>> Again, as there are well known standards, the specification has to do
>only
>> the semantics and syntax not the algorithms.
>>
>> >
>> > So for your spec, I would focus on describing the requirement
>> rather than
>> > the solution to the requirement. For example if you wanted allow
>> > the payload
>> > resulting from a reg-rep query to be digitally signed, then I would
use
>> > words along the lines of:
>> >
>> > >>>"The Payload of the Reg-Rep query MAY be signed using a XML
>Signature
>> > within the ebXML Header Document, etc...<<<
>>
>> This approach I like. We can specify the requirements. But by saying
that
>> the header MAY be signed, we are saying that the semantics and
>> syntax of the
>> operation is described somewhere, hopefully in the TRP specification.
>>
>> Again my question is, if the TRP specifies how to sign a header
>> separately,
>> then I can do what you say. But then the header - with the signature -
>> should be available at the application layer. In other words, if the
>> application can "see" the signature, then we can leverage the TRP
>> specs. But
>> if the TRP strips off the signature, we need to have some other scheme.
>>
>> Same is true with the payload signature. If the TRP verifies the payload
>> signature and strips it, then the application not only has to specify
>what
>> is required, but it needs to specify the XML elements as well.
>>
>> It is this interaction that I was abstracting as the black-box
>> behavior. May
>> be the idea all along was to pass on the header signature and payload
>> signature/encryption to the application layer. I have a related question
>-
>> have you folks discussed using SSL at the TRP layer ? If so, how will it
>> play ? Will an SSL implementation satisfy the TRP security requirements
?
>>
>> Hopefully, I have made the points more clearer.
>>
>> cheers
>>
>>
>> >
>> > David
>> >
>> > -----Original Message-----
>> > From: Krishna Sankar [mailto:ksankar@cisco.com]
>> > Sent: Tuesday, December 26, 2000 11:55 AM
>> > To: ebxml-regrep@lists.ebxml.org; Ebxml Transport; Ebxml-Ta-Security
>> > Subject: RE: Registry Security Spec Version 003
>> >
>> >
>> > Chris,
>> >
>> >  Comments embedded.
>> > cheers
>> >
>> > > -----Original Message-----
>> > > From: christopher ferris [mailto:chris.ferris@east.sun.com]
>> > > Sent: Tuesday, December 26, 2000 7:24 AM
>> > > To: Krishna Sankar
>> > > Cc: ebxml-regrep@lists.ebxml.org; Ebxml Transport; Ebxml-Ta-Security
>> > > Subject: Re: Registry Security Spec Version 003
>> > >
>> > >
>> > > Krishna,
>> > >
>> > > Some comments on your proposal.
>> <snip ../>
>>
>
>
>