HTTPBIS WG IETF 77 Issues: http://svn.tools.ietf.org/svn/wg/httpbis/wg_materials/ietf77/ietf-77-httpbis-issues.xhtml Changes (07->09): http://svn.tools.ietf.org/svn/wg/httpbis/wg_materials/ietf77/ietf-77-httpbis.xhtml Agenda and other info: http://tools.ietf.org/wg/httpbis/agenda XMPP log: http://www.ietf.org/jabber/logs/httpbis/2010-03-22.txt Archived audio stream: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf77/ietf77-ch6-mon-afnoon2.mp3 ==Agenda bash JeffH might take a few minutes to present security properties ==Changes overview (link above) Two drafts since Stockholm; changes summarized Yves: w3c is considering using time ranges as a custom range unit (re http://trac.tools.ietf.org/wg/httpbis/trac/ticket/150) ==Open issues (link above) Things that are currently being discussed - age calculation (new algorithm, please check it, see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/29), URI fragments in redirection (media type specific?, please provide input, see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43), response code caching (which codes can be cached?, see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/110), sniffing (see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/155), effective request URI (see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/196) Yves: fragment processing depends on media type, so do we need to address this in the registration of URI types that allow for fragments? Yves: (security for sniffing) add text that says that ignoring the content-type is done at the risk of those who do it, as advisory/warning Julian: and the "sniffing" draft Yves: we'll have to talk to Adam about that Alexey: "sniffing" is not well-understood outside this context jeffh: on effective URI - is this work justified? (see definition in http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html) Julian: we needed a name and your name fit (on xmpp: Mark agrees) Pending issues Jamshid Mahdavi: has implemented deflate and can explain the problem, not sure about a solution (see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/73) Mark: proposal is to note that implementations do send deflate without zlib wrappers Yves: methods and caching, but this (139) is about the story the spec has to say when we decided to use method+URI as the key for caches (which is a clarification over rfc2616 caching text) (See XMPP logs for more discussion on this point) Location header and its handling; Julian proposes to consider non-URI values in Location (such as whitespace) to continue to be errors, and to be subject to (undefined) error handling. ==Security properties http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-05 Referencing the "Overall Issue" in the draft JeffH: the issue is whether this doc is either a collection of peer-entity authentication mechanisms and picking a mandatory to implement set thereof; or if it is intended to be a collection of the nastier security problems (or cross-specification ones) Robert Sayre: Can't add MTI (mandatory-to-implement) mechanisms by charter JeffH: if this is a description of the mechanisms that are actually used, this spec is poorly named Robert: this is authn, because it's not revising 2617 Lisa: expanding might be good to avoid problems with IESG review; describing the problems is useful; wants all included, if possible JeffH: the name change is only necessary if the scope is constrained to authn Lisa: authent is a potential hotspot for argument, might need to trade-off time investment against potential benefit Barry: this might be a good place for the cross-document security considerations or the stuff common to each, those things that don't fit the individual drafts Joe H: we don't write security considerations just to placate the IESG ==RFC2231 in HTTP (see http://svn.tools.ietf.org/svn/wg/httpbis/wg_materials/ietf77/ietf-77-http2231.xhtml) Problem with Content-Disposition and I18n In IETF LC NedF: making this separate from 2231 is a good idea, it's not time to revise 2231 Ned: apologizing for 2231 shortcomings jck: profiling things out is right, agrees with Ned Julian: utf-8 would be nice for HTTP, but it's not possible ChrisN: don't allow for multiple language variants, profile that out Julian: send this to LC Ned and jck: agrees with Chris jck: the security consideration relating to comparison of utf-8 strings needs to be addressed, but it's not clear what this spec needs to include Alexey: spec revision needed Julian: profiling lang variants out is used in an RFC (link header), so profiling that out might be hard Ned: in practice, that's probably not a problem; no implementations, though there might be in the HTTP world jck: this looked like a good idea at the time, but it didn't work out; reiterates Ned Mark: implementers might have felt that it was too complex Ned: 2231 doesn't say anything about having multiple language flags, might be difficult to include based on syntax definition Julian shows example from link header draft -08: wrong draft, it's in the draft being discussed, Section 4.3 Ned: might be a problem, but it's a legitimate use case that's being demonstrated, can't object based on this jck: nervous, but potential problems with the bindings between the parameters and various over header values Yngve: this might cause problems (mentions accept-language) Ned: need good guidance on how this is used and how it interacts with similar features of the language Mark: http already has multiple ways of doing such things and there is no guidance given there Julian: this will affect the link header draft which is long past LC Alexey: we can do another LC if we need to ==Closing Discussion Alexey: when is httpbis going to close Julian: we have been slow, but plan to finish this summer, we will plan to meet in Maastrict Lisa: HTTP PATCH is now an RFC ==WebDAV ideas http://trac.tools.ietf.org/area/app/trac/wiki/DavFuture Julian: might charter a WG for this Cyrus: caldav carddav deployments are demanding more performance and some features Alexey: try to organize a bof