-
Notifications
You must be signed in to change notification settings - Fork 55
/
httpbis-minutes-77.txt
145 lines (72 loc) · 6.19 KB
/
httpbis-minutes-77.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
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