>> >> I'm arguing that the foundation for interoperation is the DIX >> protocol and >> not the binding to a specific transport protocol (HTTP). By making a >> particular binding "mandatory" for all implementations, you >> are potentially >> limiting future choices. For instance, would I be forced to >> implement HTTP >> in all XMPP and SIP clients and proxies even though XMPP and >> SIP bindings >> may exist? And that begs the question - why HTTP? > > 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.
If you really want this to be a compossible identity framework, than perhaps the path sought is really 2 drafts. One for the core specification, the other for the particular transport binding the wg feels is most likely to see adoption (or has unfulfilled requirements), which may be HTTP . It also allows other specs to incorporate nicely into some new transport. =peterd (http://public.xdi.org/=peterd) _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
