On 20-Jan-06, at 10:27 AM, Scott Hollenbeck wrote:
OK, I agree with the "why HTTP" question. That's one you guys need to
figure out. I'm telling you now, though, that a charter that does not
describe at least one method to produce interoperable
implementations will
not be approved by the IESG.
I've been chewing this over all day:
We can't mandate that the other party in the exchange implement
DIX over a particular transport. It's an implementation decision
between the user's client and the other party. We have the motivating
use cases of a VOIP phone or IM client to illustrate this.
We could mandate the transport between the user's client and their
agent. HTTP perhaps... given its simplicity and ubiquity. I do hesitate
though, because I'm sure there are use cases where that doesn't
make sense. For example my agent might actually be built into my
client so the transport is IPC or API. What use would that kind of
agent be?... well it could just be a local replica of my agent in the
internet. Hmm, is my local agent really just an agent of my agent
and therefore a non-principal party to the exchange. Agh. What if
my agent were on a USB key or a smart card? What would my
transport be then... I'm not sure... I suppose it could be HTTP...
We could state:
"To ensure interoperability between implementations we mandate
that the user's client and their agent must support at least DIX
over HTTP."
It's hard to be definitive about this without the use cases to refer
to...
I'd appreciate any comments you folk on the list have about this.
John
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
