On Wed, Mar 15, 2017 at 10:28 PM, Richard Barnes <[email protected]> wrote:
> I think you're over-stating the impacts here. The overall shape of the > protocol is untouched by these proposals, and many of them are just cleanup > for a document that's made it through 25 revisions. > https://trac.ietf.org/trac/trans/ticket/162 https://trac.ietf.org/trac/trans/ticket/170 https://trac.ietf.org/trac/trans/ticket/171 https://trac.ietf.org/trac/trans/ticket/174 https://trac.ietf.org/trac/trans/ticket/176 https://trac.ietf.org/trac/trans/ticket/185 Are all pretty substantially impacting changes. That's just a few I looked through of which meaningfully change how either a client or server is designed and implemented. I'll use https://trac.ietf.org/trac/trans/ticket/185 as an example, which I suspect is something you'd consider trivial (but I may have read wrong). As a client, this forces an additional indirection through a URL lookup service to take advantage of this. It further forces the need for policy regarding how such URLs are constructed and advertised - because as we all know, despite (or because of, depending on your view) RFC 3986, URLs are far messier in the real world, and untangling that mess just shifts the problem to policy. It touches on operational issues, such as whether or not this remains static for the duration of the log or variable. I wasn't trying to suggest we shouldn't discuss these, just that I can see a number of them are, from a client implementor hat, pretty significant, and some of them are pretty underjustified or undesirable (e.g. https://trac.ietf.org/trac/trans/ticket/171 ). I'll save the substantive comments for the individual discussions, and greatly appreciate the view to highlight what you believe are most to least pressing matters to resolve :)
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
