Draft 03 is available at: http://www.ietf.org/internet-drafts/draft-ietf-bliss-ach-analysis-03.txt
In this draft the design team has tried to capture the results of Dublin, roughly summarised as: - rewriting of text on configuring the UA, with conclusion that BLISS does not need to do anything; - adding REST as another means of configuring a proxy, together with some description; - closure of open issue to do with response code for silent rejection / global (leaving it as a possible topic to cover under anti-spit measures, rather than BLISS ACH); - additional text to do with receiving notifications that proxy ACH configuration has changed. The biggest remaining issue concerns configuration of the proxy, whether a RESTful approach or some other approach is taken, and what the exact requirements are. Another draft from Zourzouvillys addresses requirements and a draft from Griffin describes REST. The remainder of the analysis draft is reasonably complete, but we need to decide on a few things, as indicated by open issues in the draft. Please discuss on the list, rather than waiting for Minneapolis: 1. Can we fix on 480 as the response code for explicit rejection / local? Concerns have been raised about overloading this response code. 2. Do we need to write normative statements about response code usage? If so, do we need to do it in this document (in which case it would become a BCP) or elsewhere? 3. Various open issues to do with configuring the proxy. Do these need to be handled in this draft or separately? 4. Do we need to define an event package for notifying changes to the proxy configuration for ACH, and if so, does that belong in this document (which would make it standards track) or elsewhere? 5. There is an empty Conclusions section, but we need answers to the issues above before we can attempt to populate that section. John _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
