> 1. Whatever new mechanisms we recommend/derive/whatever, we need
> to think about how they work if HTTP is not the substrate protocol.
I'm not sure we have to. It may be that HTTP(S) is our goal, and while
scope will include non-HTTP, what we have to do is make sure we cover
HTTP. We may then generalize to non-HTTP as much as we can, but it may be
we should make sure we're concentrating our energies on moving rapidly
towards our main goals. That said, to the extent we cover more general
cases, that's great, and I don't want to lose that.
> Of course, none of this is as important as HTTP (or mail and
> then HTTP) use cases. I'm not saying we should devote as much
> effort at non-HTTP substrates, but we shouldn't forget them
> either IMO.
So perhaps we're saying the same thing.
> At a minimum, if someone could use another substrate
> to demonstrate how to work around whatever improvements we help
> create, then this group's work will have a credibility problem.
I disagree. It may be that our group will be applicable to other
substrates, and they should it adopt it. Or it may be that other
substrates have unique problems that we'll be setting the pattern for
fixing, in terms of a standards based group taking on usable security
challenges. I don't see how not solving something out of scope makes us
less credible. But perhaps you've got some sort of concrete "what if" in
mind that would help me see your point.
Mez
Received on Monday, 11 December 2006 16:05:05 UTC