Re: Last Call: Using SOAP in BEEP to Proposed Standard

["Marshall T. Rose" <mrose+mtr.netnews at DBC.MTVIEW.CA.US>]

lloyd - in looking at your technical concerns:

1. i am at a loss to understand the problem you perceive with respect to
mapping soap message patterns onto beep. in each of the three cases, it
looks to me that the "obvious" choice was taken. what leads you to suspect
otherwise?


2. with respect to feature negotation, i agree that the mechanism used in
the specification is about as simple as clean as you can get. as to whether
it's needed or not, that's a great question.

the delta between soap 1.0 and soap 1.1 is reasonable. what remains unknown
is what soap x.y will look like. this is why we have a feature negotiation
mechanism. to the extent that future versions of soap are compatible with
the exist versions, then it isn't needed. if a future version is
incompatible, then a feature can be defined to signal this.

> And if you *really* want to be opaque, why would you need any feature
> negotation in BEEP? You could leave that up to the SOAP versioning in
> the Envelope element...

and i agree, as long as versioning remains transparent, feature negotiation
isn't needed... i would be happy to see that it never gets used. think of it
as a very cheap insurance policy.


3. finally, i am unable to parse what you mean by:

> I am concerned by the phrase 'tuned for privacy' and use of 'beeps'
> (presumably as analogous to 'https') to suggest an equivalent level of
> security, when all that is required is the start of a user
> authentication profile.
>
> Is that really strong enough from a security perspective, or simply
> desirable from the marketing viewpoint that the phrase 'tuned for
> privacy' suggests? (I'm by no means a security expert.)

specifically, "tuning" is a term of art in beep, so anyone who knows beep
knows what "tuned for privacy" means. what problem, per se, are you worried
about?

/mtr