source: wg_materials/ietf77/httpbis-minutes-77.txt @ 2082

Last change on this file since 2082 was 798, checked in by julian.reschke@…, 10 years ago

add meeting minutes

File size: 6.2 KB
Line 
1HTTPBIS WG
2IETF 77
3
4Issues: http://svn.tools.ietf.org/svn/wg/httpbis/wg_materials/ietf77/ietf-77-httpbis-issues.xhtml
5Changes (07->09): http://svn.tools.ietf.org/svn/wg/httpbis/wg_materials/ietf77/ietf-77-httpbis.xhtml
6
7Agenda and other info: http://tools.ietf.org/wg/httpbis/agenda
8
9XMPP log: http://www.ietf.org/jabber/logs/httpbis/2010-03-22.txt
10Archived audio stream: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf77/ietf77-ch6-mon-afnoon2.mp3
11
12==Agenda bash
13
14JeffH might take a few minutes to present security properties
15
16==Changes overview (link above)
17
18Two drafts since Stockholm; changes summarized
19
20Yves: w3c is considering using time ranges as a custom range unit (re http://trac.tools.ietf.org/wg/httpbis/trac/ticket/150)
21
22==Open issues (link above)
23
24Things 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)
25
26Yves: fragment processing depends on media type, so do we need to address this in the registration of URI types that allow for fragments?
27
28Yves: (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
29
30Julian: and the "sniffing" draft
31
32Yves: we'll have to talk to Adam about that
33
34Alexey: "sniffing" is not well-understood outside this context
35
36jeffh: 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)
37
38Julian: we needed a name and your name fit (on xmpp: Mark agrees)
39
40Pending issues
41
42Jamshid 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)
43
44Mark: proposal is to note that implementations do send deflate without zlib wrappers
45
46Yves: 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)
47
48(See XMPP logs for more discussion on this point)
49
50Location 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.
51
52
53==Security properties http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-05
54
55Referencing the "Overall Issue" in the draft
56
57JeffH: 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)
58
59Robert Sayre: Can't add MTI (mandatory-to-implement) mechanisms by charter
60
61JeffH: if this is a description of the mechanisms that are actually used, this spec is poorly named
62
63Robert: this is authn, because it's not revising 2617
64
65Lisa: expanding might be good to avoid problems with IESG review; describing the problems is useful; wants all included, if possible
66
67JeffH: the name change is only necessary if the scope is constrained to authn
68
69Lisa: authent is a potential hotspot for argument, might need to trade-off time investment against potential benefit
70
71Barry: 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
72
73Joe H: we don't write security considerations just to placate the IESG
74
75==RFC2231 in HTTP (see http://svn.tools.ietf.org/svn/wg/httpbis/wg_materials/ietf77/ietf-77-http2231.xhtml)
76
77Problem with Content-Disposition and I18n
78
79In IETF LC
80
81NedF: making this separate from 2231 is a good idea, it's not time to revise 2231
82
83Ned: apologizing for 2231 shortcomings
84
85jck: profiling things out is right, agrees with Ned
86
87Julian: utf-8 would be nice for HTTP, but it's not possible
88
89ChrisN: don't allow for multiple language variants, profile that out
90
91Julian: send this to LC
92
93Ned and jck: agrees with Chris
94
95jck: 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
96
97Alexey: spec revision needed
98
99Julian: profiling lang variants out is used in an RFC (link header), so profiling that out might be hard
100
101Ned: in practice, that's probably not a problem; no implementations, though there might be in the HTTP world
102
103jck: this looked like a good idea at the time, but it didn't work out; reiterates Ned
104
105Mark: implementers might have felt that it was too complex
106
107Ned: 2231 doesn't say anything about having multiple language flags, might be difficult to include based on syntax definition
108
109Julian shows example from link header draft -08: wrong draft, it's in the draft being discussed, Section 4.3
110
111Ned: might be a problem, but it's a legitimate use case that's being demonstrated, can't object based on this
112
113jck: nervous, but potential problems with the bindings between the parameters and various over header values
114
115Yngve: this might cause problems (mentions accept-language)
116
117Ned: need good guidance on how this is used and how it interacts with similar features of the language
118
119Mark: http already has multiple ways of doing such things and there is no guidance given there
120
121Julian: this will affect the link header draft which is long past LC
122
123Alexey: we can do another LC if we need to
124
125
126==Closing Discussion
127
128Alexey: when is httpbis going to close
129
130Julian: we have been slow, but plan to finish this summer, we will plan to meet in Maastrict
131
132Lisa: HTTP PATCH is now an RFC
133
134
135==WebDAV ideas
136
137http://trac.tools.ietf.org/area/app/trac/wiki/DavFuture
138
139Julian: might charter a WG for this
140
141Cyrus: caldav carddav deployments are demanding more performance and some features
142
143Alexey: try to organize a bof
144
145
Note: See TracBrowser for help on using the repository browser.