source: wg_materials/ietf78/minutes.txt @ 1928

Last change on this file since 1928 was 952, checked in by mnot@…, 10 years ago

add minutes for IETF78

File size: 11.2 KB
Line 
1Agenda: http://tools.ietf.org/wg/httpbis/agenda?item=agenda78.html
2
31. agenda bashing
4Alexey, do we need to talk about rechartering? (thinking of HTTP Timeout)
5mnot: not now
6 
72. httpbis status (see slides)
8mnot: want to have LC in ~3 months
9new workflow allows editors to incorporate uncontroversial changes directly in the spec
10and keep state in trac
11
12Julian: previous drafts done before IETF meetings, -11 will be published soon as we made enough progress
13<list of changes, see slides>
14
15Question? -> none
16 
173. RFC2817
18mnot: how much of 2817 can be moved to httpbis (CONNECT? Upgrade?)
19<Julian> can we obsolete 2817 if we move these parts into httpbis?
20Alexey: thumbs up
21<roy.fielding> works for me
22Adam Barth: obsoleting it would be fine
23Alexey: changes are in the spirit of the WG charter
24Cyrus: one active draft reference 2817, See 4825 and wrap
25Julian: might be only the status code registry
26Martin: 4825 suggest that people use Upgrade to TLS
27Alexey: in practise we do that all the time, if there is an upgrade to xcap, it will fix the link
28 
29 4. RFC2617
30mnot: part7 is the http auth framework, the meat of auth (basic and digest) is in 2617
31issues like i18n auth scheme registry might be addressed
32a path could be to have basic and digest in one or two drafts, framework in p7
33Alexey: seems to be the right thing to do, having the framework in p7 is fine, other two documents will need a recharter
34mnot: no changes needed as a first step to produce new documents, only i18n will require changes
35Alexey: reopening digest could be controversial
36<Barry Leiba> Cyrus: I don't see that draft-ietf-vwrap-type-system <http://tools.ietf.org/wg/vwrap/draft-ietf-vwrap-type-system/> has any ref to RFC 2617.  Checking whether I got the right doc when you said that.
37<Barry Leiba> Never mind... 2817, not 2617.
38mnot: if the recharter says that only editorial changes are made, it could help.
39Cyrus: not sure IESG will accept Digest as-is
40Alexey: moving to historic might help. If somebody want to reopen Basic and Digest, it would be better if it was in a WG
41Cyrus: Mutual Auth is there as an example of new auth
42mnot: we are not a security-related WG
43<roy.fielding> How about defining a registry for auth schemes?
44Alexey: that is a good idea (in response to Roy's comment)
45 
465. Registration Policies
47Alexey: does it mean that every RFC can define new method?
48Julian looking at the relevant text
49<Julian> IETF Review: "New values are assigned only through
50 RFCs that have been shepherded through the IESG as AD-
51 Sponsored or IETF WG Documents [RFC3932] [RFC3978]"
52<roy.fielding> HTTP has historically been a gateway protocol -- arbitrary methods are supported but we have no registry for sharing.
53mnot: most important are methods and status code
54<martin.thomson> suggestion:   Standards Action - Values are assigned only for Standards Track RFCs approved by the IESG.
55Alexey: Informational is allowed by the definition
56Martin Thomson: Standards Action seems in order
57Alexey: we just need a gatekeeper
58Martin: IETF review also has a gatekeeper
59Julian: Specification required + expert review. Do we want to allow other bodies like W3C to register new methods?
60Martin: we are looking at a higher bar than just IETF review
61Alexey: How about IETF review + expert review ?
62Martin: I think that IETF review imply expert review
63=> IETF Review indeed seems to cover the case
64<Anne> requiring an RFC for a new HTTP method?
65mnot: yes (response to Anne)
66<Anne> sounds like overkill to me
67<Julian> Anne, just for the record: the RFC requirement for methods isn't new
68<Anne> kk
69mnot: probably a higher bar for auth scheme
70Alexey: you want to allow experimentaiton as well
71Martin: point of order, spec required implies expert review, no need to specify it
72Cyrus: why Transfer-Coding and Content-Coding don't require IETF review while Range would get it ?
73mnot: because we already have entries in the registry
74adam: is there spam protection for upgrade tokens?
75mnot: yes
76sam johnston: any plan to have a user-editable registry for link ?
77mnot: not in scope of this wg, will talk offline
78mnot: when you get question about what status code to use and you point to let's say a Webdav-defined status code, it is common to have a "it's webdav, not an HTTP status code", what can we do to clear up that perception ?
79can be fixed in the registration text, also in the registration procedure we can require specific document to register the status code.
80what would people think to require specific document to register status code ?
81Julian: depends on how litteral you take that, if you have 3, do you need 3 docs ?
82mnot: no
83Julian: also the shouldn't be a need to split status code and methods
84martin: maybe you want to include guidance in the registry to define what you want to put in those
85mnot: just opened new methods about guidance to define extensions like methods etc...
86 
876. Content-Disposition
88<see slides>
89Julian: people interested in security consideration for Content-Disposition are welcomed to contact me
90 
917. Active Issues
92http://trac.tools.ietf.org/wg/httpbis/trac/report/17
93
94http://trac.tools.ietf.org/wg/httpbis/trac/ticket/224
95Header Classification
96do we want to rethink header classification ?
97Martin: good suggestion from Roy to keep only connection and end-to-end headers.
98mnot: general vs entity is a confusing concept
99
100http://trac.tools.ietf.org/wg/httpbis/trac/ticket/225
101contradiction between p2 and p6 text
102<martin.thomson> conclusion was to invalidate
103people slightly in favor of invalidating
104need text for #100 about DNS spoofing, contributions welcomed
105
106http://trac.tools.ietf.org/wg/httpbis/trac/ticket/213
107<roy.fielding> The only thing left for #109 is "entity-header" classification, which we just agreed to remove.
108the spec define 1xx to 5xx while grammar allow 3 digits, is 016 or 913 allowed?
109Julian: 016 or 913 require IETF review anyway, so IANA should never see those
110mnot: also do we want to reserve a range for local use?
111adam: clarify 0xx and 6+xx in which direction ?
112mnot: clarify that they are reserved, and cannot for now be registered.
113Alexey: has tightening the ABNF discussed?
114mnot: not yet, perhaps in the future a new class will be added
115Julian: if we change the ABNF if will change a semantical error in a parsing error. Do we want to do that?
116Alexey: I will check what SMTP did
117<roy.fielding> and do the opposite ;-)
118'effective request URI', editors are talking about using 'target URI'.
119<alexey.melnikov> In SMTP: Reply-code     = %x32-35 %x30-35 %x30-39
120<alexey.melnikov> So this is more restrictive than 3DIGIT
121Jeff: Effective Request URI implies that it is not serialized on the wire. It might be good to keep the explanation in the spec
122perhaps using ERU as an acronym
123<roy.fielding> no no no
124
125http://trac.tools.ietf.org/wg/httpbis/trac/ticket/221
126Should Effective Request URI consider HTTP/1.0 ?
127Jeff: that should be noted in the spec
128mnot: but no need to define an algorithm for HTTP/1.0
129
130http://trac.tools.ietf.org/wg/httpbis/trac/ticket/222
131<roy.fielding> yeah, but the whole purpose of * is not to be a URI
132Julian: we need to come up with an URI, we need to state what that textual representation is
133Julian: if we don't define target URI for OPTIONS, there are other places in the spec where we have that issue
134<roy.fielding> those places already are special-cased for * (they must be)
135Adam: you need to have an URI for everything at the security layer.
136Martin: is * in the http scheme at all? Would a specific scheme be ok ? like "*" ?
137Alexey: nice hack, but might be difficult to register
138<roy.fielding> nope
139Adam: in CORS, "*" represent "any URI"
140=> continue on the mailing list
141<martin.thomson> suggestion wasn't serious :)
142
143http://trac.tools.ietf.org/wg/httpbis/trac/ticket/233
144is * only usable for OPTIONS ?
145some nodding heads
146Julian: OPTIONS is used a lot OPTIONS * almost never (in WebDAV)
147Martin: should we kill the star ?
148<roy.fielding> It works fine for me.
149<roy.fielding> I see no reason to stop implementing OPTION *
150<martin.thomson> use case?
151<roy.fielding> for OPTIONS
152<martin.thomson> yes
153<cyrus> for OPTIONS *
154<martin.thomson> OPTIONS * specifically
155mnot => continue on the list
156<roy.fielding> for server OPTIONS
157
158http://trac.tools.ietf.org/wg/httpbis/trac/ticket/158
159maybe define Keep-Alive in an appendix
160Yngwe: we use Proxy-Connection to indicate Keep-Alive to the proxy. don't remember why
161
162 http://trac.tools.ietf.org/wg/httpbis/trac/ticket/79
163<martin.thomson> On OPTIONS *:
164Request-URI is an asterisk ("*"), the OPTIONS request is    intended to apply to the server in general rather than to a specific    resource. Since a server's communication options typically depend on    the resource, the "*" request is only useful as a "ping" or "no-op"    type of method; it does nothing beyond allowing the client to test    the capabilities of the server. For example, this can be used to test    a proxy for HTTP/1.1 compliance (or lack thereof).
165
166<roy.fielding> The advantage of OPTIONS * is that it makes a request without identifying a specific URI, thus allowing some security issues to be discovered before revealing the traget of the next request. It also does not impact hit rates.
167
168http://trac.tools.ietf.org/wg/httpbis/trac/ticket/203
169Max-Forwards usable only for OPTIONS and TRACE ?
170...some nodding
171
172http://trac.tools.ietf.org/wg/httpbis/trac/ticket/232
173issue is about adding prose to avoid transforming UA in an Accept, with too much details
174<roy.fielding> whereas it used to be a MUST NOT?
175
176http://trac.tools.ietf.org/wg/httpbis/trac/ticket/160
177Yngwe: there are some sites that were broken while redirecting on 301/302 on POST
178
179Adam: is this linked to 307 and user prompting ?
180mnot: it is a different one, we should open an issue on user prompting
181
182http://trac.tools.ietf.org/wg/httpbis/trac/ticket/178
183 still needs discussion, a partial proposal in upcoming -11
184 http://trac.tools.ietf.org/wg/httpbis/trac/ticket/235
185<roy.fielding> I did not addess 178 yet ... just changed terms to make existing text clearer for content-md5
186<roy.fielding> we should consider deprecating content-md5 in general
187
188Active Design ticket list
189the "interesting" ones are marked 'later'
190hardest issues are #20 and #22
191<roy.fielding> http://trac.tools.ietf.org/wg/httpbis/trac/report/9
192
193http://trac.tools.ietf.org/wg/httpbis/trac/ticket/22
194
195http://trac.tools.ietf.org/wg/httpbis/trac/ticket/20
196long history, difficult to reach consensus
197Adam: do you need data for what browsers do wrt #20 ?
198mnot: more data welcomed, as browser changed
199 
2008. Memento presentation
201<see slides>
202Slide: Memento Framework
203<Julian> should look for overlap with http://greenbytes.de/tech/webdav/rfc5829.html
204stpeter: is the whole flow depending on having the original URI being active ? (including DNS)
205Herbert: it can happen from the archive
206Julian: it may be possible to re-use some recently registered link relatiions (RFC 5829)
207Carrasco: we have the same issue in the language dimension
208Martin: how do I do "monitoring state between date d1 and d2" ?
209Herbert: there are multiple relationships, one pointing to the first or the last and there is a discovery API to get a list of mementos with associated dates
210Martin: wanting for the drafts
211<stpeter> http://www.mementoweb.org/
212<stpeter> and http://www.mementoweb.org/guide/http/ has some details
213<Julian> running code!
214Herbert: there are plugins for mediawiki, a mozilla plugin, and more to come
215mnot: the earlier the discussion starts the better, in case the protocol ahs to change
216 
217ADJOURNED
Note: See TracBrowser for help on using the repository browser.