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

[Lloyd Wood <l.wood at eim.surrey.ac.uk>]

Re:  http://www.ietf.org/internet-drafts/draft-etal-beep-soap-04.txt

On Mon, 10 Sep 2001, Marshall T. Rose wrote:

> 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?

Special-casing the single-response case struck me as less than obvious
(especially given Eamon's comment that 'The spec is designed so that
it carries an envelope of SOAP data without having to know what is
inside it'). And then there's ERR use.


> 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.

Should compatibility between versions of soap be encouraged by leaving
out such mechanisms? 

Bear in mind that beep is not the only thing bound to soap, so that
having one other popular soap carrier/binding that *doesn't* bother
with doing soap version negotiation to deal with soap's future
oddities imposes the limit of compatibility on future versions of soap
here.

I don't think beep should be worrying about soap's version problems;
encouraging soap developers to actually think about compatibility and
legacy and deal with their own messes in the existing envelope
mechanism is imo a good (if perhaps overdue?) idea, and if at least
one other binding does that, beep's soap version negotiation is then
unneeded.

 
> > 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. 

Removing versioning ensures that it never gets used, and that we're
happy.


> think of it as a very cheap insurance policy.

...that encourages you to burn down your house to collect the reward.
 

> 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. 

'tuned for privacy' is not defined in RFC3080 or 3081. It's not
defined or even discussed in the full raw beep list archive at:
http://lists.beepcore.org/pipermail/beepwg.mbox/beepwg.mbox

How will beep implementors know what this term means?

Transport security, privacy, and user authentication are somewhat
different things, I'd have thought. Is it reasonable to equate them
all in 'tuned for privacy'?

Specific text comment on the definition in section 5.2 of the draft:

'tuned for transport security' strikes me as a more reasonable term,
and would require that either:

a. a transport security profile is successfully started; or,
b. a user authentication profile that *requires the use of* transport
   security is successfully started.

so that transport security is *mandated*.

Privacy is a very different beast.

cheers,

L.

<L.Wood at surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>