Re: Comments on draft-eastlake-additional-xmlsec-uris-07.txt
On 2013-02-07 03:48, Donald Eastlake wrote: ... it references RFC Errata, Errata ID 191, RFC 4051 without linking the errata item, and does so normatively even though the document as a whole I'm not sure exactly what you mean here. The errata does appear in the references as [Errata191] - RFC Errata, Errata ID 191, RFC 4051, http://www.rfc- editor.org I have been told by an Area Director that this it the format that the RFC Editor likes. You can certainly find the Errata starting with that link and by just linking to the main ref-editor.org web page, it does not constrain the other structure of that web site. ... Indeed. But maybe it's time to restate that the format the RFC Editor likes is sub-optimal. The format *readers* like is a link that actually gets you directly to the erratum. Best regards, Julian
Re: request to make the tools version of the agenda the default
On 2012-11-30 20:16, Richard Barnes wrote: On Nov 30, 2012, at 2:10 PM, Wes Hardaker wjh...@hardakers.net wrote: John C Klensin john-i...@jck.com writes: I think changing the default is fine. I'd also be reluctant to see the normal HTML version go away immediately but would be especially reluctant to see the plain text version go away or even become less accessible (require more clicks or searching to navigate too). I suspect we can all agree that this would be optimal: 1) have the tools version be the default (my original statement) 2) have the html version still present 3) have the text version still present 4) produce an xml version for better parsing (ever try and write an agenda app? Half your time is spent writing a .txt or .html parser) s/xml/json/ Ever try writing an XML app? Half your time is spent writing a .xml parser. Hahaha. Best regards, Julian
Re: Last Call: draft-snell-http-prefer-14.txt (Prefer Header for HTTP) to Proposed Standard
On 2012-10-05 17:12, Julian Reschke wrote: Hi James, see below for my (mostly editorial) feedback: I note that there was no reply to this mail, and at least one problem is still present in the latest draft...: 2.2. Examples The following examples illustrate the use of various preferences defined by this specification, as well as undefined extensions for strictly illustrative purposes: 1. Return a 202 Accepted response for asynchronous processing if the response cannot be processed within 10 seconds. An undefined priority preference is also specified: Prefer: return-asynch, wait=10; Prefer: priority=5; Shouldn't that be: Prefer: return-asynch; wait=10 Prefer: priority=5 ??? Best regards, Julian
Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-arch...@w3.org from September 2012)
On 2012-10-23 02:05, Ian Hickson wrote: ... I suspect it will break nothing, but I guess we'll find out. I don't really understand how it _could_ break anything, so long as the processing of IRI and URIs as defined by IETF is the same in the WHATWG spec, except where software already differs with the IETF specs. Define software. *All* software? How do you test that? Do you have a concrete example I could study? Do you? This brings me back to something I've been asking for many times: a *concrete* list of things that are broken in RFC 3986 (as opposed to be undefined). Best regards, Julian
websockets in the IETF, was: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-arch...@w3.org from September 2012)
On 2012-10-23 01:59, Ian Hickson wrote: ... Whether WebSockets is a good idea or not is besides the point. The point is that the hybi group was not a pleasant experience for me. If I were to be in a position to do Web Sockets again, I would decline the opportunity to do it through the IETF. Doing it through the IETF made the work take a year longer than it would have, made the protocol less secure (the WG removed a number of defense-in-depth features), and made the spec a mess ... And, as far as I can tell, fixed a security problem in the original design (which caused some UA implementers to actually disable what they were shipping at that time): http://w2spconf.com/2011/papers/websocket.pdf (it's a mishmash of different editing styles). Plus, the group _still_ hasn't done multiplexing, which some of the vendors said was a prereq to implementation, something which, prior to the IETF getting involved, was only 3 to 6 months out on the roadmap. ... Indeed, but then wasn't it you arguing *against* having it in the base spec? (see http://www.ietf.org/mail-archive/web/hybi/current/msg00239.html) Best regards, Julian
Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-arch...@w3.org from September 2012)
On 2012-10-22 19:55, Ian Hickson wrote: On Mon, 22 Oct 2012, Brian E Carpenter wrote: On 18/10/2012 02:25, Noah Mendelsohn wrote: On 10/17/2012 7:57 PM, Ian Hickson wrote: Yeah. Turns out we (the Web standards community) haven't been doing such a great job of making our specificatiosn match reality.:-( Um, true... but it's also the case that the implementation community hasn't over the years been doing as much as might be best to make reality match the specifications. The new specs we're writing now would like have been a lot thinner and cleaner if they had. However, I think the concern here is that if certain IETF specs need to be updated to match the real world, that work needs to be done in the IETF. I couldn't agree more! We've been waiting for four years for the URI working group to get their act together and fix the URL mess. Nothing has happened. We lost patience and are now doing it ourselves. ... Clarifying: there is no URI Working Group, and as far as I can tell, there is no consensus that there is a mess to fix related to URIs. There *is* indeed a *IRI* Working Group which planned to define things that occur in HTML links (including sanitizing whitespace and dealing with the problems with non-ASCII characters), and *that* WG indeed hasn't delivered yet. Best regards, Julian
Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-arch...@w3.org from September 2012)
On 2012-10-22 23:46, Ian Hickson wrote: On Mon, 22 Oct 2012, Julian Reschke wrote: I couldn't agree more! We've been waiting for four years for the URI working group to get their act together and fix the URL mess. Nothing has happened. We lost patience and are now doing it ourselves. ... Clarifying: there is no URI Working Group, and as far as I can tell, Whoever. The people complaining that it should be done at the IETF haven't done any work. That's the complaint. Until they do the work, complaining that we're doing it instead is going to fall on deaf ears and be met with the rolling of eyeballs. This always was about venue, not people. If people want to fix or augment URIs/IRIs, they should come over to the IETF. That's where the specs live. The IETF is open to anyone, works async on mailing lists, and doesn't require any membership fees. I don't think there's any standards body that is *more* open to individuals. But yes, you may have to convince a few people outside the WhatWG. That's a feature. It means more review from people outside the browser ecosystem. there is no consensus that there is a mess to fix related to URIs. The specs don't define everything that implementations have to do to be interoperable. If the IETF doesn't think that's a problem, then that's fine, but then y'all shouldn't be surprised when people who _do_ think that's a problem try and fix it. Yes, please fix *that*, but *just* that without messing with the basics without consensus/review. So yes: if you feel you need to make \ to equivalent to /, that may be ok (as \ isn't valid anyway). But changing the reference resolution algorithm for valid URI/reference pairs is something entirely different. *If* it needs to be done, it needs to be done within the scope of the URI spec. Best regards, Julian
Re: Last Call: draft-snell-http-prefer-14.txt (Prefer Header for HTTP) to Proposed Standard
Hi James, see below for my (mostly editorial) feedback: Multiple times: s/header/header field/ 1. Introduction Within the course of processing an HTTP request there are typically a range of required and optional behaviors that a server or intermediary can employ. These often manifest is a variety of subtle and not-so-subtle ways within the response. s/is/in/ For example, when using the HTTP PUT method to modify a resource -- similar to that defined for the Atom Publishing Protocol [RFC 5023] reference to RFC 5023 is missing The rigid, must-understand semantics of the Expect header, therefore, make it a poor choice for the general expression of optional preferences that may be specific to an individual application and are therefore unknown to an intermediary or are otherwise irrelevant to the intermediaries successful handling of the request and response. Another option available to clients is to utilize Request URI query- string parameters to express preferences. Doing so, however, results in a variety of issues affecting the cacheability of responses. Comment: not according to the spec; but there are other issues with it, such as overloading the URI namespace. As an alternative, this specification defines a new HTTP request header field that can be used by clients to request that optional behaviors be applied by a server during the processing the request. Additionally, a handful of initial preference tokens for use with the new header are defined. In this document, the key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [RFC2119]. ID-Nits complained it couldn't find this note. It probably needs some adjustment. 1.1. Syntax Notation This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] and includes, by reference, the token, word, OWS, BWS rules and the #rule extension as defined within Sections 1.2 and 3.2.4 of [I-D.ietf-httpbis-p1-messaging]. Note: need to re-check the section numbers, they might have moved. 2. The Prefer Request Header Field The Prefer request-header field is used to indicate that particular server behaviors are preferred by the client, but not required for successful completion of the request. Prefer is similar in nature to the Expect header field defined by Section 9.3 of [I-D.ietf-httpbis-p2-semantics] with the exception that servers are Ditto. If a particular preference token or parameter is specified multiple times, repeated occurrences MUST be ignored without signaling an error or otherwise altering the processing of the request. That means: first wins, right? The repeated occurrences might have different parameters... The Prefer request header field is end-to-end and MUST be forwarded by a proxy if the request is forwarded. That's something *this* spec can not require; it should follow from HTTPbis, right? s/header/header field/ No significance is given to the order in which preference tokens appear within a request. Really? What if a token is repeated with different parameters? 2.1. Content Negotiation and Cache Considerations Note that while the Prefer header field is not intended to be used as content negotiation mechanism, the application of a preference potentially could affect the caching characteristics of a response. Specifically, if a server supports the optional application of a preference that could even just potentially result in a variance to a cache's handling of a response entity, a Vary header field MUST be included with the response listing the Prefer header field regardless of whether the client actually used Prefer in the request. Because of the inherent complexities involved with properly implementing server-driven content negotiation, effective caching, and the application of optional preferences, implementors must ...avoid lowercase RFC2119 keywords... exercise caution when utilizing preferences in such a way as to impact the caching of a response and SHOULD NOT use the Prefer header mechanism for content negotiation. 2.2. Examples The following examples illustrate the use of various preferences defined by this specification, as well as undefined extensions for strictly illustrative purposes: 1. Return a 202 Accepted response for asynchronous processing if the response cannot be processed within 10 seconds. An undefined priority preference is also specified: Prefer: return-asynch, wait=10; Prefer: priority=5; Shouldn't that be: Prefer: return-asynch; wait=10 Prefer: priority=5 ??? 3. Preference Definitions The following subsections define an initial set of preferences. Additional preferences can be registered for convenience and/or to promote reuse by other applications. This
Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-arch...@w3.org from September 2012)
FYI: Quoting AvK in http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0297.html: The plan is to obsolete the RFCs. But yes, I will add some references in the Goals section most likely. Similar to what has been done in the DOM Standard. Note this is about RFC 3986, which is a Full Standard. Best regards, Julian
Re: [OAUTH-WG] oauth-bearer and rfc 2617/httpbis authentication framework
On 2012-07-23 00:33, Stephen Farrell wrote: Hi all, I'd like to check that some recent minor changes to this document [1] don't cause technical or process-grief. The version [2] of the oauth bearer draft that underwent IETF LC and IESG evaluation had a normative dependency on the httpbis wg's authentication framework. [3] After resolving IESG discuss positions the authors and wg chairs felt that it would be better to replace the normative reference to the httpbis wg draft [3] with one to RFC 2617 [4] so that the OAuth drafts wouldn't be held in the RFC editor queue waiting on the httpbis wg to get done. I believe there is no impact on interop resulting from this change but there has been some disagreement about making it and how it was made. After some offlist discussion I think we now have an RFC editor note [5] that means that the current scheme of referring to RFC 2617 is ok. ... Quoting: NEW: The Authorization header for this scheme follows the usage of the Basic scheme [RFC2617]. Note that, as with Basic, this is compatible with the the general authentication framework being developed for HTTP 1.1 [I-D.ietf-httpbis-p7-auth], though does not follow the preferred practice outlined therein in order to reflect existing deployments. The syntax for Bearer credentials is as follows: That helps, but it still hides the fact that the syntax is not compatible with the RFC 2617 framework. Also, s/header/header field/ Proposal: The syntax of the Authorization header field for this scheme follows the usage of the Basic scheme defined in Section 2 of [RFC2617]. Note that, as with Basic, it does not conform to the generic syntax defined in Section 1.2 of [RFC2617], but that it is compatible with the the general authentication framework being developed for HTTP 1.1 [I-D.ietf-httpbis-p7-auth], although it does not follow the preferred practice outlined therein in order to reflect existing deployments. The syntax for Bearer credentials is as follows: ... Best regards, Julian
Re: Comments for I-D of Publishing the Tao of the IETF as a Web Page
On 2012-06-21 23:08, Russ Housley wrote: This URL http://www.ietf.org/tao will bring up the current document. It works exactly the same as http://www.ietf.org/tao.html. This means that http://www.ietf.org/tao/archive cannot be used as suggested on this thread. ... Sorry?
Re: Comments for I-D of Publishing the Tao of the IETF as a Web Page
On 2012-07-04 16:52, Russ Housley wrote: Julian: Do you object to http://www.ietf.org/tao-archive for the old version of the Tao? Russ No, I was just trying to understand *why* the archive can't be at http://www.ietf.org/tao/archive. Best regards, Julian
Re: Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard
On 2012-06-11 22:31, Peter Saint-Andre wrote: ... RFC 2818 is extremely minimal in its description of the 'https' URI scheme. At least draft-ietf-httpbis-p1-messaging is a bit more complete. However, the IANA Considerations of the latter document need to be modified so that they instruct the IANA to change the data in the URI schemes registry. ... Not so: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-19.html#rfc.section.7.2 Best regards, Julian
Re: abnf discussion list?
On 2012-05-23 18:56, Dave Crocker wrote: Folks, g'day. There are periodic questions about ABNF that go beyond the specifics of a specification attempting to use it. While these are not hot topics, they do occur periodically. Also, there is support material (software, documentation) for ABNF that has no single, natural home. I'd like to suggest an abnf-disc...@ietf.org mailing list and an abnf.ietf.org web page. Thoughts? d/ Sounds good to me. Best regards, Julian
Re: RFC 2119 terms, ALL CAPS vs lower case
On 2012-05-16 22:29, Dave Cridland wrote: On Wed May 16 21:10:02 2012, Randy Bush wrote: Authors must be fastidious about this. s/this/documents/ RFC 2119 §6 says: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions). For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. I note two things: 1) RFC 2119 also uses lower-case must and may throughout. 2) RFC 2119 also clearly states that using the terms too much will harm interoperability. The second is the one I feel we have violated much more, and caused much more damage, than any possible problem with the first. ... +100
Re: [Gen-art] Gen-ART LC/Telechat review of draft-reschke-http-status-308-05
On 2012-03-16 22:06, Ben Campbell wrote: Apologies for the delayed response--the day job got in the way this week. Comments inline: On Mar 12, 2012, at 12:16 PM, Julian Reschke wrote: On 2012-03-12 17:15, Ben Campbell wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-reschke-http-status-308-05 Reviewer: Ben Campbell Review Date: 2012-03-12 IETF LC End Date: 2012-03-16 IESG Telechat date: 2012-03-15 Summary: This draft is basically ready for publication as an experimental RFC. I have a few minor comments that might be worth considering whether they would improve the document prior to publication. Note: Since this draft is on a Telechat that precedes the end of the IETF Last Call, this review serves as both the LC and Telechat review. Thanks. Major issues: None: Minor issues: -- General: I see some discussion about existing UA behavior, but nothing about what a UA should do with a 308 other than as an implication the fact that this is a permanent version of 307. It's probably worth describing that explicitly. (Or is that what the clients with link-editing capabilities statement is intended to do?If so, does that cover everything?) The draft uses *exactly* the same words as the base spec (HTTPbis), except that it combines aspects of 302 (permanence) with those of 307. I thought that's clear enough. I assume you meant 301 and 307. Yes. I note that all of the 3XX responses have their semantics explicitly described in httpbis. While some reference other 3XX codes to contrast the behavior, none seem to be defined in terms of each other. The 301 definition includes an explicit note about the POST to GET behavior. The 307 definition includes an explicit post about that behavior not being allowed. Section 3 of this doc does neither. The note in 307 was written to point out that the equivalent (308) is not defined in HTTPbis. That's why the equivalent text is not on the definition of 308. But you are right in that it provides additional information not present in the statement for 308, and I can fix that. Looking further, I see that both the 301 and 307 definitions have different language about the response payload (they say if the method was not HEAD the payload SHOULD contain short hypertext note, while this doc says the payload can contain one. (which I read as equivalent to a MAY). Finally, both 301 and 307 contain a paragraph about automatic redirection for safe methods. Both of this is not true anymore in draft -19 of httpbis, where all these statements have been moved to the introduction of the redirect codes. -- section 1, last paragraph: The fact that a 308 can't change the method is left as an implication of being based on 307. It would be good to state that explicitly and normatively here. We don't state it in HTTPbis either. 301, 302, and 303 are exceptions. See the new introduction inhttp://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.7.3. HTTPbis sections 7.3.2, 7.3.3, 7.3.4, and 7.3.8 all contain explicit language or notes about about GET and POST. I recognize that it is not stated _normatively_ in each case, but it's at least mentioned. 7.3.2 (301), 7.3.3 (392) and 7.3.4 (303) have these notes because they are exceptions. Re: 7.3.8: see above. -- section 3, 1st paragraph: Clients with link-editing capabilities ought to... Should that be stated normatively? No. Again, this is consistent with the text in HTTPbis for status code 302. I concur that it says that. I find it unfortunate that HTTPbis used non-normative language there, but the text in this draft is consistent. -- section 3, third paragraph: The new permanent URI SHOULD be given... I'm curious why that is not a MUST. Is there a reasonable (i.e. interoperable) way to send a 308 _without_ a URI in the location field? Is the meta refresh directive something that can be used _instead_ of the Location header field? Again, consistency with RFC 2616 and HTTPbis. You are correct. -- section 4: The example uses _both_ the location field and the HTMLmeta refresh directive. Is this considered a recommended practice to the degree you might normatively recommend it in the text? No, it's a hack that makes deployment easier until all UAs do the right thing; we don't want to make that permanent. A comment to that effect in the text would be helpful. I disagree with this. It's an example for a deployment strategy that can help in the short term. That's all. Best regards, Julian
Re: Last Call: draft-reschke-http-status-308-05.txt (The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)) to Experimental RFC
Hi there, the IESG has approved the draft for publication as experimental, but a few details need some tuning. I plan to post a revised draft next Monday (when publication restarts), and have my current version available over here: http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-latest.html Diffs relative to the WGLC draft can be found here: http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-latest-from-wglc.diff.html The main changes so far are updates to references, an addition of an informal ref to the HTML spec (because of the example using HTML), a warning against attempting to do UA sniffing, plus the inclusion of a note that makes the definition more consistent with what HTTPbis says about status code 307. Feedback appreciated, Julian On 2012-02-17 16:53, Julian Reschke wrote: (FYI) Also, an HTML version with feedback links is available at http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-05.html. Best regards, Julian On 2012-02-17 15:45, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)' draft-reschke-http-status-308-05.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the additional HyperText Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect). The file can be obtained via http://datatracker.ietf.org/doc/draft-reschke-http-status-308/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-reschke-http-status-308/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-reschke-http-status-308-05.txt (The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)) to Experimental RFC
On 2012-03-17 13:50, Julian Reschke wrote: Hi there, the IESG has approved the draft for publication as experimental, but a few details need some tuning. I plan to post a revised draft next Monday (when publication restarts), ... Monday, March 26, actually...
Re: Gen-ART LC/Telechat review of draft-reschke-http-status-308-05
On 2012-03-12 18:48, Peter Saint-Andre wrote: ... hat type='AD'/ Julian, I think it would be helpful for you to submit your latest copy before the deadline today, so that we don't need to wait until March 26. Done; I usually avoid changing drafts during LC; but I think it makes sense in this case. Best regards, Julian -- green/bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht Münster: HRB5782 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC/Telechat review of draft-reschke-http-status-308-05
On 2012-03-12 17:15, Ben Campbell wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-reschke-http-status-308-05 Reviewer: Ben Campbell Review Date: 2012-03-12 IETF LC End Date: 2012-03-16 IESG Telechat date: 2012-03-15 Summary: This draft is basically ready for publication as an experimental RFC. I have a few minor comments that might be worth considering whether they would improve the document prior to publication. Note: Since this draft is on a Telechat that precedes the end of the IETF Last Call, this review serves as both the LC and Telechat review. Thanks. Major issues: None: Minor issues: -- General: I see some discussion about existing UA behavior, but nothing about what a UA should do with a 308 other than as an implication the fact that this is a permanent version of 307. It's probably worth describing that explicitly. (Or is that what the clients with link-editing capabilities statement is intended to do?If so, does that cover everything?) The draft uses *exactly* the same words as the base spec (HTTPbis), except that it combines aspects of 302 (permanence) with those of 307. I thought that's clear enough. -- section 1, last paragraph: The fact that a 308 can't change the method is left as an implication of being based on 307. It would be good to state that explicitly and normatively here. We don't state it in HTTPbis either. 301, 302, and 303 are exceptions. See the new introduction in http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.7.3. -- section 3, 1st paragraph: Clients with link-editing capabilities ought to... Should that be stated normatively? No. Again, this is consistent with the text in HTTPbis for status code 302. -- section 3, third paragraph: The new permanent URI SHOULD be given... I'm curious why that is not a MUST. Is there a reasonable (i.e. interoperable) way to send a 308 _without_ a URI in the location field? Is the meta refresh directive something that can be used _instead_ of the Location header field? Again, consistency with RFC 2616 and HTTPbis. -- section 4: The example uses _both_ the location field and the HTMLmeta refresh directive. Is this considered a recommended practice to the degree you might normatively recommend it in the text? No, it's a hack that makes deployment easier until all UAs do the right thing; we don't want to make that permanent. Nits/editorial comments: None Note that I have an updated version waiting to be submitted in two weeks (or earlier, if the AD allows me to). It updates references, and adds an informative ref to the HTML spec, as suggested during LC. See http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-latest.html. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
On 2012-03-06 14:41, Xavier Marjou wrote: As a subscriber of the i-d-annou...@ietf.org list, I generally prefer reading the HTML version of the draft rather than the TXT version. I thus often need to manually rewrite the TXT link to fetch the HTML version of the draft. I can not believe I'm the only one. Hence, would it be possible to also include a link like http://tools.ietf.org/html/draft-name in the mail of the announced draft? ... +1000 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
On 2012-03-06 14:56, Yoav Nir wrote: Even better, also add the XML2RFC output if it's available at the same time: http://tools.ietf.org/id/draft-name.html for example, (just picking my own latest draft as an example): http://tools.ietf.org/id/draft-nir-websec-extended-origin-02.html +1 I don't know which drafts get this version (perhaps those submitted along with XML?), but they're sure easier to read than TXT. Indeed I'd like to understand that as well. In particular, as this apparently runs an outdated version of rfc2629.xslt, and then mangles it's output (HTML tidy maybe?) causing what's served to be invalid HTML. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
On 2012-03-06 16:26, Yoav Nir wrote: The XML2RFC version is not linked from there. If that was added to the Other versions field, that would be great. ... Indeed. HTMLized plain text is progress over plain text, but properly generated HTML is better. But I fear we're getting close to our beloved permathread. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-rmt-flute-revised-13.txt (FLUTE - File Delivery over Unidirectional Transport) to Proposed Standard
On 2012-02-29 16:53, Vincent Roca wrote: Hello Julian, I note that draft-ietf-rmt-flute-revised is on the agenda. Just wanted to note that I haven't seen any feedback to my LC comments on the ietf-discuss mailing list... I didn't see you initial email (I'm not not on the ietf@ietf.org mailing list), which explains why you didn't receive any feedback. Well, you don't need to be on the mailing list, but you certainly should scan the mailing list archives. After all, this is the place where the Last Call asks for feedback. --- Co-authors: there are a few comments for which I'd appreciate to have your input. They are prefixed with: = Co-authors. --- Here are a few comments, mainly of editorial nature: Below my review notes; just mechanical checks, and some checks on the relation to HTTP header fields...: Section 3: File name (usually, this can be concluded from the URI). In the above example: file.txt. ...or the Content-Disposition header field (RFC 6266). VR: The sender can freely choose a solution to convey the filename. We suggest to use the URI to that purpose. What you suggest (Content-Disposition) is an alternative. Current text seems to be appropriate in the sense that: 1- it only suggests one solution; 2- it does not close the door, and using another solution remains valid; I'm also a little bit confused by what RFC6266 / RFC2616 say, namely that Content-Disposition is not part of HTTP/1.1. RFC 6266 has registered Content-Disposition as header field for HTTP. As such, it overrides anything that 2616 said about it. That being said; it's advisory only, but I thought it might be worthwhile to mention. My feeling is to let the text as it is today. If anybody else has a different opinion... File type, expressed as MIME media type. In the above example: text/plain. s/MIME media type/internet media type/ VR: okay, Internet media type is indeed the appropriate term. Corrected. NEW: File type, expressed as Internet Media Types (often referred to as MIME Media Types). In the above example: text/plain. 3.4.2: Where the MD5 message digest is described, the attribute Content-MD5 MUST be used for the purpose as defined in [RFC2616]. Note that Content-MD5 is gone from HTTPbis. VR: We are not using MD5 message digest to protect ourselves from deliberate attacks, but only as a reasonable way to be confident of the decoded object integrity WRT transmission or FLUTE/ALC processing errors. The probability of message digest collision is in that case so small it makes sense to still use it for that purpose. Additionally, Content-MD5 is part of the 3GPP MBMS Rel.6 specifications. Removing it altogether from the FLUTE-revised document would be an error from a backward compatibility point of view, even if we know that this version is not backward compatible. My feeling is to leave it as it is to minimize differences WRT to RFC3926. XML-Schema: I believe the spec should state what to do with invalid input. Are there extension points (like ignoring unknown elements in extension namespaces)? VR: it seems reasonable, indeed. I'd like to hear other opinions. What about the following text (last sentence is added)? NEW: Any valid FDT Instance MUST use the above XML Schema. This way FDT provides extensibility to support private attributes within the file description entries. Those could be, for example, the attributes related to the delivery of the file (timing, packet transmission rate, etc.). Unsupported private attributes SHOULD be silently ignored by a FLUTE receiver. = Co-authors, do you agree? So any undefined attributes should be ignored. What about undefined elements? It is RECOMMENDED that the new attributes applied in the FDT are in the format of MIME fields and are either defined in the HTTP/1.1 specification [RFC2616] or another well-known specification. As this is a normative requirement it needs to be clarified what header fields are used? HTTP? MIME? VR: Sorry, I don't understand the point (my HTTP/MIME understanding is probably too limited). HTTP header fields and MIME header fields are not the same thing. Pick one. Also, well-known is irrelevant, we have a registry for header fields. VR: Right. I've added a pointer to the IANA Internet Media Type registry and an informative reference. However I prefer to keep the or another well-known specification part of the sentence, since removing it might create issues. Such as? NEW: It is RECOMMENDED that the new attributes applied in the FDT are in the format of MIME fields and are either defined in the HTTP/1.1 specification [RFC2616], or another well-known specification, or in IANA registry [IANAmediatypes]. MIME fields isn't a term used in the IETF. (see above). NEW reference: [IANAmediatypes] IANA, IANA Media Types registry, URL:
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
On 2012-02-26 10:44, Yoav Nir wrote: ... Could you please explain why you think tying this effort to HTTP/2.0 is necessary to achieve that? To me that's the critical bit, and I still haven't seen the reasoning (perhaps I missed it). I think I have *an* answer to this, though probably not *the* answer. There's two stages to adoption - implementation and roll-out. Obviously you can't roll out new authentication before the browsers and servers implement it. For my website, I wouldn't roll out new auth if only one or two of the browsers out there implemented it. Even if all the big ones (IE, Firefox, Chrome, Opera) did, I would still have to provide a backwards compatibility authentication scheme to support older browsers. This would lead to both inconsistent UI and to ugly javascript that detects the browser version, and makes the roll-out slower. You can send multiple challenges in one response. We could also define a way to make HTML-form-based login an HTTP scheme (see http://tools.ietf.org/id/draft-broyer-http-cookie-auth-00.txt) to integrate better what people use today. If any HTTP/2.0 browser is bound to have new authentication it makes things much easier. This could be circumvented by adding request headers that advertise capabilities, but I don't think we like those much. I don't believe we need those. If we do, we should retrofit this into 1.1 as well. Anyway, I see lots of theoretical discussion about process. What's needed is people doing the actual work, both spec-wise and implementation-wise. That's the critical problem. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
On 2012-02-25 14:46, Stephen Farrell wrote: ... Yeah that's a tricky one. While one might like to see one or more in both places that might not be practical. In the proposal above the goal is that httpbis pick one or more but recognising the reality that we might not get a new proposal that httpbis will accept and that folks will really implement and deploy. So: Goal = one or more Reluctant recognition of reality = zero or more With this plan if httpbis in fact select zero new proposals that would represent a failure for all concerned. The zero or more term is absolutely not intended to provide a way to just punt on the question. Such a failure at the point where httpbis was re-chartering to work on a HTTP/2.0 selection with no better security than we now have is probably better evaluated as a whole - I guess the question for the IETF/IESG at that point would be whether the Internet would be better with or without such a beast, or better waiting a while until the security thing did get fixed. I can imagine an argument might ensue about that;-) ... If we just need a new authentication scheme, nothing stops people from working on that right now. I don't see how that should affect HTTP/2.0. If the right way to do security needs changes in the HTTP/1.1 authentication framework, then we should fix/augment/tune HTTP/1.1. It's not going to go away anytime soon. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
On 2012-02-25 15:13, Stephen Farrell wrote: On 02/25/2012 02:03 PM, Julian Reschke wrote: On 2012-02-25 14:46, Stephen Farrell wrote: ... Yeah that's a tricky one. While one might like to see one or more in both places that might not be practical. In the proposal above the goal is that httpbis pick one or more but recognising the reality that we might not get a new proposal that httpbis will accept and that folks will really implement and deploy. So: Goal = one or more Reluctant recognition of reality = zero or more With this plan if httpbis in fact select zero new proposals that would represent a failure for all concerned. The zero or more term is absolutely not intended to provide a way to just punt on the question. Such a failure at the point where httpbis was re-chartering to work on a HTTP/2.0 selection with no better security than we now have is probably better evaluated as a whole - I guess the question for the IETF/IESG at that point would be whether the Internet would be better with or without such a beast, or better waiting a while until the security thing did get fixed. I can imagine an argument might ensue about that;-) ... If we just need a new authentication scheme, nothing stops people from working on that right now. I don't agree with you there - the perceived low probability that something will be deployed is a real disincentive here. We have had people wanting to do work on this and have been told there's no point because it won't get adopted. Just checking: so you think what's needed is a normative requirement to implement the new scheme? Do you really believe that that's what holding up improvements in this area? I don't see how that should affect HTTP/2.0. Well, a number of people have noticed that current schemes are getting long in the tooth and fixing stuff like that when you do a major rev of a protocol is quite a reasonable thing to do. If there's something from with the framework, let's fix the framework. That's already covered by the current charter, no? If the right way to do security needs changes in the HTTP/1.1 authentication framework, then we should fix/augment/tune HTTP/1.1. It's not going to go away anytime soon. Sure, I agree with that and think the plan above allows for it. My point being: this is something we already do in httpbis. What's missing is concrete bug reports. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
On 2012-02-25 18:44, Stephen Farrell wrote: ... I don't think fixing or changing the framework will give us better auth schemes by itself. (Better auth schemes may or may not require changes to the framework, I dunno.) So I think you're raising a side issue here really. ... Well, I'm one of the editors of the authentication framework spec, so if there's something wrong with it, I'd like to know. So if we collectively think that the framework probably is ok, and that we *do* need a new authentication scheme, what's stopping us to start that activity *right now*? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
On 2012-02-22 18:01, RJ Atkinson wrote: Earlier, Barry Leiba wrote, in part: What we're looking at here is the need for an HTTP authentication system that (for example) doesn't send reusable credentials, is less susceptible to spoofing attacks, and so on. +1 More generally, I support the concerns raised by Stephen Farrell, Wes Hardaker, and others that if *any* work is to be done on HTTP, then improving the authentication/confidentiality properties ought to be a mandatory part of that work. I'm still waiting for somebody to explain why this can't already be defined as HTTP/1.1 authentication mechanism. The IETF has LOTS of experience that if strong(er) security mechanisms are not *required* in a WG Charter *very explicitly*, then that work will not happen at all. Whether work happens nor not IMHO depends on getting the right people. Security that works well and is practical to implement needs to be designed-in, not bolted-on later. I would say: security needs to be orthogonal. Separately, I would also like to see the known-weak cryptographic algorithms/modes (i.e. published literature indicates that an algorithm, a mode, or both is weak) that are included with HTTP (as separate from being part of TLS) formally get deprecated as part of any HTTPbis work. For example, the WG ought to consider deprecating the use of the MD5, UNIXsum, and UNIXcksum algorithms within HTTP Digests [RFC-2617] [RFC-3230]. So far HTTPbis was not chartered to revise any existing auth scheme (just the framework). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
On 2012-02-23 23:33, Doug Barton wrote: I don't *quite* go back 2 decades, but a big +1 to all my experiences with bolt-on security have been bad. bolt-on != modular/optional If you want to require security in whatever comes out of this activity, you better define what security means, and also explain what keeps you from doing it right now. Again: is there anything in the HTTP/1.1 authentication *framework* that prevents a good authentication scheme to be defined? I really like to know. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
On 2012-02-22 08:04, David Morris wrote: On Tue, 21 Feb 2012, Michael Richardson wrote: Barry == Barry Leibabarryle...@computer.org writes: Barry OAuth is an authorization framework, not an authentication Barry one. Please be careful to make the distinction. Barry What we're looking at here is the need for an HTTP Barry authentication system that (for example) doesn't send Barry reusable credentials, is less susceptible to spoofing Barry attacks, and so on. and is implemented in HTTP, not in terms of HTML forms, yet has all the flexibility of the HTML form method? And includes the ability for the user to logoff / the server reset the login? Is that a protocol problem or a user agent problem? -- http://lists.w3.org/Archives/Public/www-archive/2012Jan/0023.html Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
On 2012-02-21 19:26, Stephen Farrell wrote: Down below, for the proposed HTTP/2.0 work it says: * Reflecting modern security requirements and practices In some earlier discussion I asked what modern means there. It seems to mean at least working well with TLS, but I'm not sure what else is meant, if anything. In particular, I think it'd be good to try get better (more usable, more secure etc.) HTTP authentication defined as a built-in part of HTTP/2.0. My initial take is that if we're not going to do this for a major revision of the protocol, then when are we going to do it? So I'd like to see that included. The counter argument offered was that better HTTP authentication is complex and probably hard to get right and so would be better handled separately. I believe this should be orthogonal to HTTP/2.0. Is there a specific thing that makes it impossible to use the existing authentication framework? ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
On 2012-02-21 19:37, Stephen Farrell wrote: ... I believe this should be orthogonal to HTTP/2.0. Is there a specific thing that makes it impossible to use the existing authentication framework? Who knows? We don't have a protocol on the table yet. I would imagine that some level of backwards compatibility would be a requirement of course, or at least an issue to be considered. But the existing HTTP client authentication is also not necessarily very useful, and there have been a number of efforts to improve on that, none of which seem to have gotten sufficient traction to get widely deployed/used. Maybe HTTP/2.0 is a good time to try fix that. Well, we have an existing authentication framework. It would be interesting to find out what's missing from it. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-rmt-flute-revised-13.txt (FLUTE - File Delivery over Unidirectional Transport) to Proposed Standard
On 2012-02-11 01:48, The IESG wrote: The IESG has received a request from the Reliable Multicast Transport WG (rmt) to consider the following document: - 'FLUTE - File Delivery over Unidirectional Transport' draft-ietf-rmt-flute-revised-13.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. ... Here are a few comments, mainly of editorial nature: Below my review notes; just mechanical checks, and some checks on the relation to HTTP header fields...: Section 3: File name (usually, this can be concluded from the URI). In the above example: file.txt. ...or the Content-Disposition header field (RFC 6266). File type, expressed as MIME media type. In the above example: text/plain. s/MIME media type/internet media type/ 3.4.2: Where the MD5 message digest is described, the attribute Content-MD5 MUST be used for the purpose as defined in [RFC2616]. Note that Content-MD5 is gone from HTTPbis. XML-Schema: I believe the spec should state what to do with invalid input. Are there extension points (like ignoring unknown elements in extension namespaces)? It is RECOMMENDED that the new attributes applied in the FDT are in the format of MIME fields and are either defined in the HTTP/1.1 specification [RFC2616] or another well-known specification. As this is a normative requirement it needs to be clarified what header fields are used? HTTP? MIME? Also, well-known is irrelevant, we have a registry for header fields. 8.1: Actually, what's requested is a URN for the XML namespace (urn:ietf:params:xml:ns:fdt). That's fine; I don't think the XML schema needs to be registered. Otherwise, see http://tools.ietf.org/html/rfc3688#section-3.2. 8.2: Has the media type registration been reviewed on ietf-types? 8.3: You need to define the IANA procedure (see RFC 5226). Appendix B: The example contains a schemaLocation with a relative (URI) reference (ietf-flute-fdt.xsd). That's misleading, right? References: Please cite W3C spec with their full details, like this: http://greenbytes.de/tech/webdav/rfc2629xslt/w3c-references.html#ref-REC-xmlschema-1-20010502 Speaking of which; shouldn't you cite the Second Edition? [RMT-SIMPLE-AUTH]: this should be cited using the default ID style, in which case xml2rfc will add the helpful work-in-progress label Should RFC2357 be in the references? You may want to cite RFC3986 (URI). Formatting: I note that in-document links haven't been generated using xml2rfc's linking features; this way references to section numbers can break easily. I did not check those. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-reschke-http-status-308-05.txt (The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)) to Experimental RFC
(FYI) Also, an HTML version with feedback links is available at http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-05.html. Best regards, Julian On 2012-02-17 15:45, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)' draft-reschke-http-status-308-05.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the additional HyperText Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect). The file can be obtained via http://datatracker.ietf.org/doc/draft-reschke-http-status-308/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-reschke-http-status-308/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-nottingham-http-new-status-03
On 2012-01-30 16:05, Stephen Hanna wrote: Mark, I don't want to rehash the discussion that we've already had. Clearly, you prefer brevity while I would prefer education in this instance. I can live with your text for status codes 428, 429, and 431. For 511, I don't think it's adequate to just say that big security issues already exist. You should at least give some suggestions for how to deal with them. For example, you could point out that most user agents include some indication of whether the server has been authenticated. For captive portals, this indication will generally not be displayed so the user receives some warning that the response did not come from the requested URL. Are you referring to HTTPS? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-nottingham-http-new-status-03
Well, a) this doesn't help for non-HTTPS traffic, anb b) in case of a captive portal intercepting https traffic, we would expect a certificate error, no? Anyway; this is not a security consideration specific to 511, but applies to captive portals in general, no matter whether the new status code is used or not. As such, it *could* be added to Appendix B. Best regards, Julian On 2012-01-30 16:22, Stephen Hanna wrote: Yes -Steve -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Monday, January 30, 2012 10:10 AM To: Stephen Hanna Cc: Mark Nottingham; draft-nottingham-http-new-sta...@tools.ietf.org; sec...@ietf.org; ietf@ietf.org Subject: Re: secdir review of draft-nottingham-http-new-status-03 On 2012-01-30 16:05, Stephen Hanna wrote: Mark, I don't want to rehash the discussion that we've already had. Clearly, you prefer brevity while I would prefer education in this instance. I can live with your text for status codes 428, 429, and 431. For 511, I don't think it's adequate to just say that big security issues already exist. You should at least give some suggestions for how to deal with them. For example, you could point out that most user agents include some indication of whether the server has been authenticated. For captive portals, this indication will generally not be displayed so the user receives some warning that the response did not come from the requested URL. Are you referring to HTTPS? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The
On 2012-01-25 03:14, Bjoern Hoehrmann wrote: ... +1 ... If you want to keep the distinction, you should offer an argument why this is something individual schemes should regulate (since having the same rules for all schemes is much simpler). ... Exactly. I've been asking this many times, but I'm not getting any answers except we prefer it this way. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
On 2012-01-23 16:58, Julian Reschke wrote: On 2012-01-23 16:46, The IESG wrote: The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' draft-ietf-oauth-v2-bearer-15.txt as a Proposed Standard ... Please see my comments in https://www.ietf.org/mail-archive/web/oauth/current/msg08120.html which I think have not been addressed. ... In an off-list conversation I heard that what I said before may not be as clear as it could be. So... 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme. 2) In the IANA considerations, it references the registration procedure defined in http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3 (now -18, but that doesn't matter here). 3) That document recommends in http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3.1: o The parsing of challenges and credentials is defined by this specification, and cannot be modified by new authentication schemes. When the auth-param syntax is used, all parameters ought to support both token and quoted-string syntax, and syntactical constraints ought to be defined on the field value after parsing (i.e., quoted-string processing). This is necessary so that recipients can use a generic parser that applies to all authentication schemes. 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has been mentioned that it might not have ignored it if it had UPPERCASE requirements, but in HTTPbis we try to restrict BCP14 keywords to the actual protocol, not on recommendations on other specs. 5) The registration requirement for a new scheme is IETF review, which RFC 5226 defines in http://tools.ietf.org/html/rfc5226#section-4.1 as: IETF Review - (Formerly called IETF Consensus in [IANA-CONSIDERATIONS]) New values are assigned only through RFCs that have been shepherded through the IESG as AD- Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The intention is that the document and proposed assignment will be reviewed by the IESG and appropriate IETF WGs (or experts, if suitable working groups no longer exist) to ensure that the proposed assignment will not negatively impact interoperability or otherwise extend IETF protocols in an inappropriate or damaging manner. In this case the WG exists (it's HTTPbis), and the OAuth got two reviews from HTTPbis pointing out the problem -- from Mark Nottingham, the WG chair, and myself, one of the authors. And yes, I believe the way OAuth defines the syntax *will* impact interoperability. Also, I haven't seen any explanation why OAuth can not follow the recommendation from HTTPbis. Hope this clarifies things, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
On 2012-01-25 01:03, Mike Jones wrote:
Per the discussion at
http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html, the working
group's rationale for supporting quoted-string but not token syntax for these
parameters, and for requiring that backslash ('\') quoting not be used when
producing them is as follows:
Once again, the current text reflects a consensus decision of the working group.
It was viewed that requiring support for multiple ways of doing the same thing
unnecessarily complicated implementations without any compensating benefit; better to
support one syntax for each semantic operation and require all implementations to use
it.
Mike, you continue to ignore that WWW-Authenticate needs to be processed
by generic parsers, as a single instance can contain challenges for
different schemes.
If you disagree with the text below:
o The parsing of challenges and credentials is defined by this
specification, and cannot be modified by new authentication
schemes. When the auth-param syntax is used, all parameters ought
to support both token and quoted-string syntax, and syntactical
constraints ought to be defined on the field value after parsing
(i.e., quoted-string processing). This is necessary so that
recipients can use a generic parser that applies to all
authentication schemes.
(which is from the text defining the registry you are using), then
please come over to the HTTPbis WG and ask for a change. It's
work-in-progress.
Despite Julian's remarks below, the syntax in the Bearer spec *is* compatible
with standard parameter parsers, and so no interoperability problems are
created by restricting the parameter syntax to a subset of the syntax allowed
by HTTPbis. No non-standard code is needed to use parameters in the manner
described in the Bearer spec.
That is not true. Using standard components will cause recipients to
accept invalid field instances, which *is* an interoperability problem.
This has happened before: RFC 2617 states that the realm parameter needs
to be quoted, but we see that all browsers accept the token form as well
(http://greenbytes.de/tech/tc/httpauth/#simplebasictok). That's not a
surprise because it's the natural thing to do with a generic parser.
Please don't add to the mess. In particular when there really is no
reason to do so. All I heard from you is: we prefer it that way. I'm
sorry, but that's not sufficient.
...
Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
On 2012-01-23 16:46, The IESG wrote: The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' draft-ietf-oauth-v2-bearer-15.txt as a Proposed Standard ... Please see my comments in https://www.ietf.org/mail-archive/web/oauth/current/msg08120.html which I think have not been addressed. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
On 2012-01-23 18:24, Mike Jones wrote: As editor of the Oauth Bearer spec, I believe that these comments have been well understood and considered by the working group. I do understand that the working group's consensus position is different than Julian's. See these notes documenting that this is the case: https://www.ietf.org/mail-archive/web/oauth/current/msg08113.html https://www.ietf.org/mail-archive/web/oauth/current/msg08116.html https://www.ietf.org/mail-archive/web/oauth/current/msg08121.html ... We are going in circles; see https://www.ietf.org/mail-archive/web/oauth/current/msg08118.html. I can only recommend that people who want to know what's going on read the complete mail thread. Also I'd like to point out that I *did* recommend to go to IETF LC despite these issues because I believe that more review from outside the WG is needed here. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ishikawa-yrpunl-ucode-urn-01.txt (A URN Namespace For The ucode) to Informational RFC
On 2012-01-17 19:27, Mykyta Yevstifeyev wrote: Hello, Having reviewed this document, I think there is no problem with its publication. Several tiny comments: 1) RFID in the Introduction needs expanding at first use. 2) ucode-value = 32hex-decimal hex-decimal = 0 / 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 / 9 / A / B / C / D / E / F may be changed to: ucode-value = 32HEXDIG and that's RFC 5234 which definesHEXDIG so you may refer to it later. 3) Rules for lexical equivalence: The entire UCODE-URN is case-sensitive. This is at least wrong for the first three chars in URN (the URI scheme name urn), that is case-insensitive as per RFC 3986. What's the reason for setting such regulation? ... What's case-sensitive depends on context; for instance, when comparing XML namespace URIs or Atom IDs, everything is case-sensitive. See also http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.6.2. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-nottingham-http-new-status-03
On 2012-01-13 20:59, Stephen Hanna wrote: I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies new HTTP status codes for a variety of common situations. Although I am not an HTTP expert, it seems to me that this document is clear, well-written, and reasonable. +1 From a security perspective, this document seems to have little impact either positive or negative. However, the Security Considerations section does not meet our usual standards. While the authors include a subsection on each new status code, they do not explain clearly what the security implications are for each status code and how any possible negative impacts could be reduced. In general, the proposed new codes just allow to describe a problem more clearly; previously, a more generic status code would have to be used. As such, they do not change security at all. Riccardo Bernardini already commented on this issue during IETF LC. However, I do not agree with Mr. Bernardini that sections 7.1 and 7.2 are not security related. Rather, the security implications are just not clearly stated. For example, section 7.2 points out that servers may not want to always use the 429 status code when receiving too many requests from one client. This has security implications in that a server under attack with excessive requests from one client may compound the problem by queuing 429 status codes for every request from that client. However, this is not stated explicitly in section 7.2. Fleshing out the subsections Servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps. of section 7 (Security Considerations) should help solve the problem by providing a clear description of security problems related to these result codes and recommended mitigations. Section 7.4 does a decent job of describing the problems but fails to describe mitigations. I think that having the client use HTTPS instead of HTTP for important requests and limiting the effects of HTTP (not HTTPS) responses is an obvious mitigation. It's not the job of this spec to completely describe security considerations with respect to captive portals. All the spec does is defining a new status code that, when used, makes captive portals a bit better to work with. I do have a question about the issues raised in Appendix B. These are all legitimate issues. However, it seems to me that having status code 511 should help with these. A Indeed; that's why 511 is there in the first place. The introduction to Appendix B should state that. ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2012-01-01 09:25, Mykyta Yevstifeyev wrote: Julian, all, When I came to fixing the examples section per received comments, I first began to refine the example on references to separate disclosures, and what I got was: html ... Please visit a rel=disclosure href=http://example.org/ipr/meta-spec/; the IPR page/a for the list of patent disclosures made with respect to this specification. ... /html (unchanged fragment of list) and, later, a rel=disclosure href=https://datatracker.ietf.org/ipr/1097/;IPR Disclosure #1097/a (this was fixed to suit real situation with RFC 5925). And, after a closer look, I realized that the separate-patent-disclosure semantics and a list-thereof one are completely different. That is a simple and compelling reason, I think, to distinguish the semantics. And that's why we have 'item' and 'collection' relations (now in LC) defined as pair (actually, what my document defines may be considered to be a special case of these in some way). The only thing is that such proposed definition is different from the current W3C's use of 'disclosure' relation, which is used as my proposed 'disclosure-list', but once we have defined both, W3C will migrate to a new, correct one (I hope). All the best, and happy New Year, Mykyta Yevstifeyev ... Not convinced. I thought the purpose was to document an existing use? Now you're adding another one (post-LC), and it's (as far as I can tell) totally unclear what the W3C's take on this is. (they introduced the link relation, after all) Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2012-01-01 19:13, Bjoern Hoehrmann wrote: * Thomas Roessler wrote: I'm not interested in a game of process nomics. If you are not interested in discussing whether it was premature ... to request publication of this document as an RFC then don't suggest that it was? The IETF is currently discussing proper procedures for this kind of third-party registration in various places like happiana, you will excuse that some of us are interested in finding suitable guidelines. Speaking as liaison, I've already pointed you at the appropriate people to ask for review. This being an individual, informational draft, I think it's fair to expect the submitter to go and secure the appropriate review. I think it's fair to expect you to keep people in the W3C apprised about developments in the IETF relevant to their work, and I think it's fair to dismiss your opinion in this matter given that you don't want to dis- cuss it. Mykyta Yevstifeyev made a draft, interested parties were made aware of the draft, and after some weeks with no comments from them, as far as I am aware, Mykyta Yevstifeyev asked for publication of the draft as RFC. I don't think there is anything wrong with that. If you disagree perhaps you can find someone to argue your point on the happiana list so we can give better guidance to our fellow community members. Björn, I'm almost with you. However, changing the actual definition and adding an additional post LC would be kind of surprising, wouldn't it? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2011-12-27 07:52, Mykyta Yevstifeyev wrote: Hello, I'd like to seek consensus on separating the semantics of link relation for separate disclosure and a list thereof, correspondingly defining two link relations - 'disclosure' and 'disclosure-list'. You may see my edits made to Section 2 of the doc. below, which I'm proposing: 2. 'disclosure' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI [RFC5988] MUST refer to a particular patent disclosure made with respect to the material being referenced by context IRI. 3. 'disclosure-list' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI MUST designate a list of patent disclosures made with respect to the material being referenced by context IRI. As the doc. is in Last Call now, in order not to initiate a new one, please comment on these changes before January 6, so that I could know which version I should submit for IESG evaluation. ... I don't see a compelling reason to distinguish both. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-nottingham-http-new-status-03.txt (Additional HTTP Status Codes) to Proposed Standard
On 2011-12-16 17:57, Riccardo Bernardini wrote: Hi all, just a couple of doubts about this draft 1) In Section 3 (about code 428 Precondition Required) it is said that Responses using this status code SHOULD explain how to resubmit the request successfully. The example shown in Section 3 shows an error message embedded in an HTML document. What make me a bit uneasy is that a precondition was required, but not inserted, usually it is not a fault of the user, but of the client software. I am not sure that any explanation associated with the error could be useful to the user... ...not to the user, but potentially to somebody debugging the code. 2) Are really section 7.1 and 7.2 security related or would it better to merge them with Section 3 and 4? Just a doubt... Riccardo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
On 2011-12-14 17:06, Cyrus Daboo wrote: Hi Julian, --On December 14, 2011 12:10:27 AM +0100 Julian Reschke julian.resc...@gmx.de wrote: On 2011-12-02 00:41, The IESG wrote: ... Abstract This specification defines an extension to WebDAV that allows efficient synchronization of the contents of a WebDAV collection. - Expand acronyms on first use. Really, doesn't everyone know what WebDAV is by now :-) In any case fixed in my working copy. Just being pro-active :-). The less happens ion AUTH48, the better. Typically, the first time a client connects to the server it will need to be informed of the entire state of the collection (i.e., a full list of all member URIs that are currently in the collection). That is done by the client sending an empty token value to the server. This indicates to the server that a full listing is required. I think it would be more consistent with other specs not to send an empty token, but to send *no* token. Existing implementations expect an empty sync-token element. I don't really see much difference either way on this, so would prefer to leave it as-is. Would be interesting to know how they treat missing sync tokens. ... Actually, RFC 4918 defines member URL; maybe worth adjusting or pointing out it's the same. Will make that change in my working copy. BTW member URI does appear in 4918 in two places... Errata, errata! Marshalling: The request URI MUST identify a collection. The request body MUST be a DAV:sync-collection XML element (see Section 6.1), which MUST contain one DAV:sync-token XML element, and one DAV:prop XML element, and MAY contain a DAV:limit XML element. The request MUST include a Depth header with a value of 1 or infinity. This report definition is in conflict with the definition of the REPORT method in RFC 3253 (http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.6). Essentially, a report is applied to just the request URI (depth: 0 or no depth header field), the request URI and it's internal members (1) or all descendants (infinity). A report definition should define the response for the case of Depth: 0. The format for the other cases follows directly from RFC 3253: If a Depth request header is included, the response MUST be a 207 Multi-Status. The request MUST be applied separately to the collection itself and to all members of the collection that satisfy the Depth value. The DAV:prop element of a DAV:response for a given resource MUST contain the requested report for that resource. (Note that I have complained about this a long time ago, http://lists.w3.org/Archives/Public/w3c-dist-auth/2007JulSep/0041.html). To fix this, the report would need to define Depth: 0 processing on a collection to mean the changes just on that collection (which means membership changes, but not changes to member resources), and the other modes would then follow based on RFC 3253. It doesn't seem to be possible to make this change in a way that doesn't break existing implementations, as RFC 3253 requires the report response format to be well-formed XML (thus only one root element), and that format then to be used *inside* DAV:multistatus/DAV:reponse/../DAV:prop. Optimally, this should be fixed. If this can't be fixed I'd argue that the spec should be published as Informational, and that it should include an explanation of the incompatibilty (essentially requiring servers to special-case this report in case they already use a generic WebDAV REPORT framework). I am not convinced the use of Depth in sync report is violating the definition in 3253. In some ways it is a matter of how you look at the It does. RFC 3253 defines the response format for Depth 0, and then states how the format for Depth 0 is derived from that; essentially by packaging into multistatus. This means that reports that do not support Depth 0 can not be defined. It also means that a report that uses multistatus for Depth 0, and which supports depths 0, will have to packages multistatus inside multistatus. sync. Your viewpoint is that the report asks the collection for its changes - in that case, yes, Depth:0 would apply. The other view is that the report asks each of the child resources to list their change status, in which case Depth:1 and Depth:infinity also makes sense. Which viewpoint is taken probably depends on actual implementation rather than any perceived protocol restrictions. What Depth 0 means is just a matter of definition. If you want to make Depth 0 mean request-URI and all of it's direct members, that's fine. It just will give funny results when you use it with other Depths *and* follow the RFC 3253 definition in these cases. Given that I feel the sync report is vital for WebDAV operations, for in particular CalDAV and CardDAV, I want to ensure this draft proceeds as a standard, not informational. If you feel strongly about this use of Depth, in spite of my comments above, then I would be willing to make some changes
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
On 2011-12-14 18:01, Ken Murchison wrote: Cyrus Daboo wrote: I am not convinced the use of Depth in sync report is violating the definition in 3253. In some ways it is a matter of how you look at the sync. Your viewpoint is that the report asks the collection for its changes - in that case, yes, Depth:0 would apply. The other view is that the report asks each of the child resources to list their change status, in which case Depth:1 and Depth:infinity also makes sense. Which viewpoint is taken probably depends on actual implementation rather than any perceived protocol restrictions. My $.02: I look the sync report as a filtered query for properties (e.g. CALDAV:calendar-query), with the filter being only give me a DAV:response if the resource has been changed/removed since the specified sync-token. A Depth of 1 or infinity gives us exactly what is specified in the draft. A Depth of 0 refers to the collection itself, and assuming it exists, the DAV:multistatus response may or may not include a single DAV:response element, depending on whether the server maintains an entity tag on the collection which changes with its membership. In either case, the sync-token is returned per the extended grammar in 6.3. So, a sync-collection report with a depth of 0 might simply return the following: D:multistatus D:sync-tokenhttp://example.com/ns/sync/1234/D:sync-token /D:multistatus Does this make sense, or is my logic completely convoluted? If this was designed from scratch, it wouldn't be using multistatus, but would include the properties of the collection (if changed). D:sync-result ... other collection props the report asked for ... D:sync-tokenhttp://example.com/ns/sync/1234/D:sync-token /D:sync-result ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
On 2011-12-14 18:27, Cyrus Daboo wrote: Hi Julian, --On December 14, 2011 5:29:16 PM +0100 Julian Reschke julian.resc...@gmx.de wrote: I am not convinced the use of Depth in sync report is violating the definition in 3253. In some ways it is a matter of how you look at the It does. RFC 3253 defines the response format for Depth 0, and then states how the format for Depth 0 is derived from that; essentially by packaging into multistatus. This means that reports that do not support Depth 0 can not be defined. It also means that a report that uses multistatus for Depth 0, and which supports depths 0, will have to packages multistatus inside multistatus. Well I don't consider the text there very clear at all. In fact I think it is very much tailored to the 3253 use cases and not flexible enough for other general purpose use of REPORT. It states this: The DAV:prop element of a DAV:response for a given resource MUST contain the requested report for that resource. It states what it states :-) Which implies packaging of multistatus within the DAV:prop element, which seems completely wrong to me. No, you only need to package multistatus inside prop in case the response to the Depth: 0 request uses multistatus. sync. Your viewpoint is that the report asks the collection for its changes - in that case, yes, Depth:0 would apply. The other view is that the report asks each of the child resources to list their change status, in which case Depth:1 and Depth:infinity also makes sense. Which viewpoint is taken probably depends on actual implementation rather than any perceived protocol restrictions. What Depth 0 means is just a matter of definition. If you want to make Depth 0 mean request-URI and all of it's direct members, that's fine. It just will give funny results when you use it with other Depths *and* follow the RFC 3253 definition in these cases. So would it hurt to allow this spec to override the 3253 nested multistatus requirement in the interests of generating a compact response specific to this type of report? I think so, because it defeats WebDAV stacks from executing reports consistently. (And, I assure you, I have written a framework in the past that did exactly that, otherwise I probably wouldn't have noticed the problem). Given that I feel the sync report is vital for WebDAV operations, for in particular CalDAV and CardDAV, I want to ensure this draft proceeds as a standard, not informational. If you feel strongly about this use of Depth, in spite of my comments above, then I would be willing to make some changes, provided we also include a statement on backwards compatibility (i.e., in an appendix state that clients/servers MAY use/accept the old Depth approach). If we do that we would need to proceed as follows: state that sync report can only be used with Depth:0, add a new request header to define the scope of the sync (e.g. Sync-Depth with values 1 and infinite). If we require Sync-Depth to be present, then we have a means for servers to detect old clients and handle Depth in a backwards compatible manner. Not happy having to add a new header field just for that. A simpler approach might be to just assign a different report name, and then allow all depths. I think if you insist on requiring Depth = nested multistatus, then we either add a new header or perhaps a depth element inside the request body (and that would also be reasonable in terms of being able to support backwards compatibility). At this point I would prefer the later as being least disruptive to existing implementations. Yes, a new child element of the request body (depth) works for me. In the case where a mapping between a member URI and the target collection was removed, then a new mapping with the same URI created, the member URI MUST be reported as changed and MUST NOT be reported as removed. The client could tell that this happened if the DAV:resourceid property was included. A member URI MUST be reported as changed if its mapped resource's entity tag value (defined in Section 3.11 of [RFC2616]) has changed since the request sync-token was generated. It should be mentioned that this only works well with resources that are not content-negotiated. Unless the content negotiation was done as part of the original full sync request? How would that work? For instance, the common case for Conneg is using Accept:, but Accept: on REPORT specifies the expected media type for the REPORT response. Yes, that's a problem with WebDAV in general. OK, so we should probably punt on per-resource content-negotiation within the report itself (though I could see us wanting to support that in the future, in which case it would probably be done through extensions elements in the request body). So what do we need to do to address this? State that the etags returned in the report are always for the non-content-negotiated representation of each child resource? I think that is already implied
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
On 2011-12-14 18:34, Cyrus Daboo wrote: Hi Ken, --On December 14, 2011 12:29:18 PM -0500 Ken Murchison mu...@andrew.cmu.edu wrote: D:sync-result ... other collection props the report asked for ... D:sync-tokenhttp://example.com/ns/sync/1234/D:sync-token /D:sync-result I don't necessarily see a problem with sync report using multistatus, but perhaps the sync-token should be returned in a prop response element for the collection rather than as an added element of multistatus. That won't work when the limiting/truncation option is used as the multistatus response for the collection indicates an overall status error, rather than using propstat. OK, so it would need to be part of the sync-result (and the other props be included with a DAV:prop container). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2011-12-13 20:07, Mykyta Yevstifeyev (М. Євстіфеєв) wrote: ... Maybe it's worth pointing out that this does not apply as verbatim instruction, but as HTML example. I have that - in source code. Maybe I should add in HTML source code? The latter sounds good. It would be good to confirm with the W3C that this actually is a requirement and not only a suggestion (cc'ing the author of PUBRULES). And I have this as well, as I've introduced this extract with must look like. I'd like to see this confirmed by the W3C. Such provisions existed in previous versions of Publication Rules as well, so such source text is often found in different W3C documents that predated publication of RFC 5988 significantly. However, 'disclosure' relation type has not been mentioned in RFC 5988 when creating the registry for relation types; nor was it registered separately. I think the paragraph above is misleading. It was not the point of RFC 5988 to define all current link relations (it *did* add existing HTML4 relations and Atom relations to the new registry but that's a separate thing). This may be read as if RFC 5988 is to determine all the rel types that were used at the time of its writing, but I don't think the paragraph directly implies this. I mean that it hasn't been registered either centralized (in RFC 5988) or separately here. Well, it doesn't say anything interesting, and might confuse people to think this was an oversight in 5988. Just drop it. 2. 'disclosure' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI MUST either (1) designate a list of patent disclosures, or (2) refer to a particular patent disclosure made with respect to the material being referenced by context IRI. I think in both cases the patent disclosure(s) apply to the context, no? Yes. I may change to: Whenever the 'disclosure' relation is defined, the target IRI MUST either (1) designate a list of patent disclosures, or (2) refer to a particular patent disclosure made with respect to the material being referenced by context IRI. to improve readability. OK. This section provides several examples of possible use of 'disclosure' relation type. If the page http://example.org/ipr/meta-spec/ contains a list of patent disclosures made with respect to the specification found at http://example.org/specs/meta-spec/spec.html, the latter would have the following fragment of HTML source code: html ... Please visit a rel=disclosure href=http://example.org/ipr/meta-spec/; the IPR page/a for the list of patent disclosures made with respect to this specification. ... /html Or, in the case of Link header field, the HTTP response would contain the following header field: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List (Please note that the actual header field will not contain the line break after 'rel' parameter.) It could if the second line was indented; maybe adjust the example? I have: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List both lines are indented with 5 Courier white spaces, and so I think my explanation in parentheses is correct. Well, HTTP header fields start at column 0 in a message. Of course you can indent your examples, but my point was that if you indent the second line *more*, it would be valid. Like this: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
On 2010-06-08 09:14, Julian Reschke wrote: On 07.06.2010 17:11, Werner Donné wrote: Hi, I don't see why Depth:infinity should be ruled out from the start. You can let the server decide if the performance penalty is too high or not. A server with a relational system underneath it, for example, can do this with one query. I don't agree with the bubble up principle. A collection changes when its member set changes. Changing a resource that is referred to by one of the members doesn't affect the collection, whether that resource is a collection or not. I think the bubble up principal is not consistent with the getlastmodified property. It is also not needed if Depth:infinity is supported. Best regards, Werner. Agreed. In particular: defining a report works by defining it for Depth: 0. The semantics for Depth: 1 and Depth: infinity follow by the definition in RFC 3253. It's probably *really* time to pull the definition of REPORT out of RFC 3253 and place it into a separate spec, including more rationale, recommendations for defining new reports, and examples. Best regards, Julian It seems to me that this issue was never addressed. As defined right now, the way REPORT is used doesn't seem to be compatible with the definition of REPORT in RFC 3253, and the definition of the Depth: header field in RFC 4918. Unless I'm missing something, this will be a problem for any implementation that tries to implement the sync report based on a generic WebDAV reporting framework. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
On 2011-12-02 00:41, The IESG wrote: ... Abstract This specification defines an extension to WebDAV that allows efficient synchronization of the contents of a WebDAV collection. - Expand acronyms on first use. Typically, the first time a client connects to the server it will need to be informed of the entire state of the collection (i.e., a full list of all member URIs that are currently in the collection). That is done by the client sending an empty token value to the server. This indicates to the server that a full listing is required. I think it would be more consistent with other specs not to send an empty token, but to send *no* token. As an alternative, the client might choose to do its first synchronization using some other mechanism on the collection (e.g. some other form of batch resource information retrieval such as PROPFIND, SEARCH [RFC5323] , or specialized REPORTs such as those defined in CalDAV [RFC4791] and CardDAV [I-D.ietf-vcarddav-carddav]) The CardDAV reference will need to be updated... To implement the behavior for this report a server needs to keep track of changes to any member URIs and their mapped resources in a collection (as defined in Section 3 of [RFC4918]). This includes Actually, RFC 4918 defines member URL; maybe worth adjusting or pointing out it's the same. Marshalling: The request URI MUST identify a collection. The request body MUST be a DAV:sync-collection XML element (see Section 6.1), which MUST contain one DAV:sync-token XML element, and one DAV:prop XML element, and MAY contain a DAV:limit XML element. The request MUST include a Depth header with a value of 1 or infinity. This report definition is in conflict with the definition of the REPORT method in RFC 3253 (http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.6). Essentially, a report is applied to just the request URI (depth: 0 or no depth header field), the request URI and it's internal members (1) or all descendants (infinity). A report definition should define the response for the case of Depth: 0. The format for the other cases follows directly from RFC 3253: If a Depth request header is included, the response MUST be a 207 Multi-Status. The request MUST be applied separately to the collection itself and to all members of the collection that satisfy the Depth value. The DAV:prop element of a DAV:response for a given resource MUST contain the requested report for that resource. (Note that I have complained about this a long time ago, http://lists.w3.org/Archives/Public/w3c-dist-auth/2007JulSep/0041.html). To fix this, the report would need to define Depth: 0 processing on a collection to mean the changes just on that collection (which means membership changes, but not changes to member resources), and the other modes would then follow based on RFC 3253. It doesn't seem to be possible to make this change in a way that doesn't break existing implementations, as RFC 3253 requires the report response format to be well-formed XML (thus only one root element), and that format then to be used *inside* DAV:multistatus/DAV:reponse/../DAV:prop. Optimally, this should be fixed. If this can't be fixed I'd argue that the spec should be published as Informational, and that it should include an explanation of the incompatibilty (essentially requiring servers to special-case this report in case they already use a generic WebDAV REPORT framework). The response body for a successful request MUST be a DAV: multistatus XML element, which MUST contain one DAV:sync-token Maybe s/one/a single/ ... Preconditions: (DAV:valid-sync-token): The DAV:sync-token element value MUST be a valid token previously returned by the server. A token can become invalid as the result of being out of date (out of the range of change history maintained by the server), or for other reasons (e.g. collection deleted, then recreated, access control changes, etc...). Does the sync-token need to originate from the same collection? 3.3. Depth behavior Servers MUST support both Depth:1 and Depth:infinity behavior with the DAV:sync-collection report. Clients MUST include either a Depth:1 or Depth:infinity request header with the DAV:sync-collection report. See above; this contradicts the base definition of REPORT. In the case where a mapping between a member URI and the target collection was removed, then a new mapping with the same URI created, the member URI MUST be reported as changed and MUST NOT be reported as removed. The client could tell that this happened if the DAV:resourceid property was included. A member URI MUST be reported as changed if its mapped resource's entity tag value (defined in Section 3.11 of [RFC2616]) has changed since the request sync-token was generated. It should be
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2011-12-09 18:58, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The 'disclosure' Link Relation Type' draft-yevstifeyev-disclosure-relation-00.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. ... I think it would have been wise if the author actually had sent a review request to the link relation mailing list, first (see http://tools.ietf.org/html/rfc5988#section-6.2.1). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2011-12-11 15:19, Mykyta Yevstifeyev (М. Євстіфеєв) wrote: 11.12.2011 16:13, Julian Reschke wrote: On 2011-12-09 18:58, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The 'disclosure' Link Relation Type' draft-yevstifeyev-disclosure-relation-00.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. ... I think it would have been wise if the author actually had sent a review request to the link relation mailing list, first (see http://tools.ietf.org/html/rfc5988#section-6.2.1). Julian, I have: http://www.ietf.org/mail-archive/web/link-relations/current/msg00296.html ... and additionally even to apps-discuss: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03420.html ... I haven't recognized that as a registration request, it would have been helpful to mark it as such in the subject line (again, see http://tools.ietf.org/html/rfc5988#section-6.2.1). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
Hi there, feedback below: 1. Introduction RFC 5988 [RFC5988] defined a way of indicating relationships between resources on the Web. This document specifies a new type of such relationship - 'disclosure' Link Relation Type. It designates a list of patent disclosures or a particular patent disclosure itself made with respect to material for which such relation is specified. s/-/- the/? Active use of 'disclosure' relation type has been identified. The current version of W3C Publication Rules [W3C-PUBRULES], Bullet 36 of Section 5, defines that each W3C document must have the boilerplate referring to the page where one may find patent disclosures made with regard to such document. As W3C Publication Rules are applied to many documents, that might be under different patent policies, a number of variants of the mentioned boilerplate exist. However, the phrase W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. can be found in each of these variants. Publication Rules specify that, in the source code, it must look like: W3C maintains a a rel=disclosure href=...public list of any patent disclosures/a made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. Maybe it's worth pointing out that this does not apply as verbatim instruction, but as HTML example. It would be good to confirm with the W3C that this actually is a requirement and not only a suggestion (cc'ing the author of PUBRULES). Such provisions existed in previous versions of Publication Rules as well, so such source text is often found in different W3C documents that predated publication of RFC 5988 significantly. However, 'disclosure' relation type has not been mentioned in RFC 5988 when creating the registry for relation types; nor was it registered separately. I think the paragraph above is misleading. It was not the point of RFC 5988 to define all current link relations (it *did* add existing HTML4 relations and Atom relations to the new registry but that's a separate thing). 2. 'disclosure' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI MUST either (1) designate a list of patent disclosures, or (2) refer to a particular patent disclosure made with respect to the material being referenced by context IRI. I think in both cases the patent disclosure(s) apply to the context, no? This section provides several examples of possible use of 'disclosure' relation type. If the page http://example.org/ipr/meta-spec/ contains a list of patent disclosures made with respect to the specification found at http://example.org/specs/meta-spec/spec.html, the latter would have the following fragment of HTML source code: html ... Please visit a rel=disclosure href=http://example.org/ipr/meta-spec/; the IPR page/a for the list of patent disclosures made with respect to this specification. ... /html Or, in the case of Link header field, the HTTP response would contain the following header field: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List (Please note that the actual header field will not contain the line break after 'rel' parameter.) It could if the second line was indented; maybe adjust the example? Appendix A. Acknowledgments Thanks to Bjoern Hoehrmann for noticing that 'disclosure' relation is not properly specified and, correspondingly, initiating this work. The author would also like to acknowledge the contributions of TBD to this document. Who's this TBD guy? :-) Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2011-12-11 21:05, Julian Reschke wrote: Hi there, feedback below: ... Forgot one more thing. The registry already contains the copyright link relation; maybe it would be good to explain who these are different. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: the success of MIME types was Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-29 09:32, t.petch wrote: ... You will be aware of the recent threads on apps-discuss about MIME types (of ... Internet Media Types :-) ... which the text/plain you mention is one) which concluded, AFAICS, that there is no rationale why a (top level) type should or should not exist, there are no criteria for creating new ones, that it is impossible to draw up a taxonomy of types because there is no underlying logic in any dimension. Yes, that's a discussion about top-level types. I don't think there was disagreement *here* (as opposed to, for instance, the WHATWG) about having the types in general. ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx
On 2011-11-27 19:38, Frank Ellermann wrote: ... bandwidth plans. PDF/A is an unrelated goal, e.g., I don't care about the monospaced font details as long as it is monospaced and can handle the simple i18n examples in IRIbis or EAI presentations. ... Hear, hear. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-26 21:52, Yaakov Stein wrote: That leaves ASCII, a few forms of PDF, and RFC 5198-conforming UTF-8. That wouldn't bother me much, but be careful what you wish form. What we have been told is that the rationale behind the use of ASCII and several other formats is that they will remain readable on devices that will be used X years hence. ASCII is already unreadable on many popular devices and in a few years will be no better than old versions of word. ... Can we *please* distinguish between the character encoding we use (US-ASCII) and the file format (text/plain)? If *we* don't get this right, how can we expect anybody else to get it right? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-27 09:20, Yaakov Stein wrote: Dave I agree that we are thinking as content creators, and that is the problem. The requirement is not that we will be able to write a new document in 50 years in the same format. The requirement is that we should be able to read the documents written 50 years before. The problem about ASCII art is not simply the monospacing. The main problem is the line wrapping. I have tried many times to look at ASCII art on iPhones, iPods, and even small pads. Once you zoom down sufficiently to get the lines not to break, the characters are no longer readable. For a screen size of about 60 mm, 80 character lines means that the characters are only 0.75mm in width. Even assuming a short figure that could be viewed rotated (width 110 mm) each character width would be only slightly more than the 1 mm needed for viewing, and less than the 1.5 mm needed for actual reading. Put in another way, high-end cellphone screens presently have 640 pixel widths. For 80 character layouts, this translates to 8 pixels per character plus inter-character spacing, or about 6 pixel character widths. Even were they visible (and each pixel is less than 1/10 of a mm!) this would mean very low quality fonts - 5*7 was the lowest quality used by old dot-matrix printers. And modern software is not optimized for readability at that font resolution. So, if we expect people to be able to read our documents in 5 years, let alone 50, we need to stop using ASCII art. ... I don't think that the format is the problem in this case. If we artwork is too wide for a narrow device as ASCII art, it will also be too wide in other format, such as SVG. What's important is that things that *should* work well on small displays, such a reflowing prose paragraphs, and re-pagination, do so. This is where text/plain fails big (and HTML does not). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
On 2011-11-27 17:20, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. ... I think something is wrong if we seriously consider that writing new reader tools is the solution to whatever we think our problem is. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-28 18:21, Ted Ts'o wrote: On Mon, Nov 28, 2011 at 06:12:42PM +0100, Julian Reschke wrote: What's important is that things that *should* work well on small displays, such a reflowing prose paragraphs, and re-pagination, do so. This is where text/plain fails big (and HTML does not). That's more of an attribute of the text reader than any thing else. I've had readers that reflow text just fine --- far better than PDF, at any rate. It requires a format that does allow reflowing and repagination. HTML does, PDF/A does, text/plain does not (maybe RFC 2646 would help, maybe not). text/plain is what we use, and that's a problem that'll need to be solved. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-28 18:46, Eric Burger wrote: Hacking text display applications when HTML was designed for it already and most RFC's natively generate HTML (xml2rfc), do we really have a problem to solve? ... If all documents were submitted in xml2rfc format (or something equally expressive): not really. We could just generate easy-to-read documents in addition to the official text/plain format, and pretend there's no problem :-). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-28 19:24, Theodore Tso wrote: On Nov 28, 2011, at 12:27 PM, Julian Reschke wrote: It requires a format that does allow reflowing and repagination. HTML does, PDF/A does, text/plain does not (maybe RFC 2646 would help, maybe not). text/plain is what we use, and that's a problem that'll need to be solved. In practice, reflowing RFC-formatted text/plain works just fine. You have to skip the page headers, but it's really not that bad. Yes, ASCII-art won't work well --- but a 800x600 SVG jpeg won't work well on a 3 screen anyway. Ok, so it works well except when it does not. Not convinced. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-28 20:29, John C Klensin wrote: --On Monday, November 28, 2011 18:27 +0100 Julian Reschke julian.resc...@gmx.de wrote: That's more of an attribute of the text reader than any thing else. I've had readers that reflow text just fine --- far better than PDF, at any rate. It requires a format that does allow reflowing and repagination. HTML does, PDF/A does, text/plain does not (maybe RFC 2646 would help, maybe not). text/plain is what we use, and that's a problem that'll need to be solved. Julian, PDF/A is a page-image format, just like base PDF. I think there is enough information present to permit reflowing lines and repaginating, but that certainly is not the intent. I think it's the intent with the reflowable feature. (It may not be used a lot, but it's there; it requires consideration on generation time, though). ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-28 20:44, Martin Rex wrote: ... The real problem is buggy software for displaying on small displays. Reflowing ASCII is *no* problem whenever ASCII text is reflowable at all. It can be done in 1-2 KByte of code. Displaying HTML or XML But our format currently is not reflowable. Can we make it? And if we do so, do we have clients to display it? usally requires more than a megabyte of code. ... So? And btw. most of the Web pages that I try print out on paper have truncated borders, waste lots of paper because only a small portion of the surface is used for information and sometime only the first page gets printed (the rest only accessible inside the browser with a scroll bar). Use a proper browser (- Firefox), and make sure to do print preview. How to print ASCII text is the type of problems for which easy solutions existed already 20 years ago. That some modern devices fail to display ascii text in a reasonable fashion is a demonstration that the software in these devices is defective, not that it is not possible to sensibly display ascii on such devices. No, it just shows that our format has been optimized for a use case which almost nobody cares about anymore. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-28 22:09, Martin Rex wrote: Julian Reschke wrote: On 2011-11-28 20:44, Martin Rex wrote: ... The real problem is buggy software for displaying on small displays. Reflowing ASCII is *no* problem whenever ASCII text is reflowable at all. It can be done in 1-2 KByte of code. Displaying HTML or XML But our format currently is not reflowable. Can we make it? And if we do so, do we have clients to display it? ASCII itself is fully reflowable. Web Browsers that are displaying HTML are actually reflowing ASCII pretty much on every page. Web browsers that display text/html are reflowing text pretty much on every page. Yes, that's my point. Again: please distinguish between character encodings and file formats. Web browsers are *not* reflowing text/plain, and that's the format we currently use. But there are two things that cause problems: * reflowing ascii arts makes the information incomprehensible That's why you need markup so the browser knows what is what. * displaying ascii arts with variable width fonts distorts the information up to incomprehensibility That's why you need markup so the browser knows what is what. Since plain ascii does not contain hints about reflowability, the visualization software would need to account for two things: * a heuristic to ensure that lines that should not be reflowed are not reflowed. Looking at the amount of whitespace (empty lines) and left to the text (indent) is often sufficient. Maybe. Maybe not. Proposal: take Henrik's rfcmarkup tool and tune it so that it *reliably* distinguishes between reflowable stuff and what's not (examples, diagrams, tables, whatnot). Once you get this working in more than a few sample documents I'll likely tell you: great, but why didn't you produce HTML in the first place? * display non-flowed text with a fixed-width font (which normally means that the flowed text should also be displayed with a fixed-width font by default) I disagree, but that's another thing HTML allows you to control. Really, displaying ascii text was a *solved* problem 30 years ago, where the common environment was 8-bit CPU, 2 Mhz clock cycle and 1-2 kByte of code for display text. It would almost a no-brainer to make this work on smartphones and pads--so unless one is stuck in a no-brain situation... So go ahead, do it. I don't mean to be rude but telling people that it's simple doesn't help. Do it. When modern display devices, which claim to be *made* for reading text, can not adequately display ASCII text that is pre-formatted for 80chars line-length, then it is first of all a clear shortcoming of the software on these devices and the engineers responsible for this software. No, it's just a sign that the world today is different from the world 30 years ago. During this summer holiday, I tried to use my childs Nintendo DSI (256x192 3.25 inch display, WLAN-support, Opera Browser) for reading a few news headlines in a language I am more accustomed to than french. I only used it with HTML pages, but it was a royal PITA as far as usability goes, inspite of HTMLs flowability. Yes. What does this prove? There are Phones with displays of 128 pixels across. Where is the limit? I think it would be worthy goal to get proper display of RFCs on 7 inch tables in portrait mode, or dedicated ebook readers of that size. ... usally requires more than a megabyte of code. ... So? Fix the obviously broken readers of new devices rather than requiring 30 full years of computing history being re-edited and re-published just so that the dense creators of those devices do not have to add 1-2 KByte of code for sensibly visualizing ASCII text (which seems too much to ask compared to the megabytes of code-updates that vendors have to regularly provide due to other shortcomings and negligences in the security area.) And btw. most of the Web pages that I try print out on paper have truncated borders, waste lots of paper because only a small portion of the surface is used for information and sometime only the first page gets printed (the rest only accessible inside the browser with a scroll bar). Use a proper browser (- Firefox), and make sure to do print preview. I do and it regularly doesn't work. Many sites render well only in specific browser and print badly, if at all. Yes. You need to consider printing when generating the HTML. You also need to consider printing when generating text/plain. But with the latter it's much harder because you need to known the paper dimensions beforehand. How to print ASCII text is the type of problems for which easy solutions existed already 20 years ago. That some modern devices fail to display ascii text in a reasonable fashion is a demonstration that the software in these devices is defective, not that it is not possible to sensibly display ascii on such devices. No, it just shows that our format has been optimized
XML-based registry format, Re: Re: watersprings.org archive of expired Internet Drafts
On 2011-10-10 11:23, t.petch wrote: Julian On a thread on this list some time ago, IANA reported progress in converting their web site to XML and at the same time, apologised for how long it now takes to access the Port Registry. Having accessed it - a good chance to complete The Times crossword! - I found an XML file in excess of 1Mbyte on my workstation. Making a wild leap of imagination, I guessed that the time it took to access the web page was due, at least in part, to these multi-megagbytes of XML, but I could be wrong. Tom Petch ... Yes, that does load slow. The reason is not XML per se, but apparently the fact that the HTML table that get's generated client-side doesn't render until the transformation is finished. And yes, if the server sends XML + XSL, this is what ends up on your machine. Otherwise it would have been HTML or TXT. That's by design. Anyway, nothing of this applies to the tools.ietf.org thingy. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: watersprings.org archive of expired Internet Drafts
On 2011-10-08 09:20, t.petch wrote: ... I want an I-D and I know fairly accurately what it is called although my reference might be to an out-of-date version, or perhaps to a version that is yet to be adopted by a WG with a consequent name change. The brilliance of watersprings was I could go click, click, click and be there, with a list of close relatives, all on one page, NOTHING TO TYPE. The curse of WIMPS is having to move between mouse and keyboard. All keyboard is a pain, I can never remember when to use Ctl-Alt-back arrow etc. All mouse is a dream, and watersprings gave me that. ... If I'm looking for an internet draft where I only know parts of the name I usually use a search engine; that's what they are for. With the current flavour of the IETF web site, I usually go via charters - WG - I-D list and then find 103 I-Ds in an order I cannot divine, give up and accept that I will have to type in d r a f t - i e t f - w g etc etc. Another waste of my time along with gif download, xml processing etc oh, did I mention all the javascripts that try to out think me and get in the way? mutter mutter ... What does XML have to do with all of this? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-melnikov-mmhs-header-fields-04.txt (Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail) to Informational RFC
On 2011-09-15 18:46, Mykyta Yevstifeyev wrote: ... 9) I'd like you hereby disallowed further registration of header fields beginning with MMHS, likewise RFC 5504 Downgraded prefix (http://tools.ietf.org/html/rfc5504#page-18). ... No. It's a bad idea in RFC 5504, and it would be a bad idea here. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] IESG note?, was: Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On 2011-09-03 20:51, Joel Martin wrote: Roy, You may feel that the wording of your note is not pejorative (because what you wanted to say is so much more so), but the tone and wording come across that way even if it is technically accurate. Having a note in the spec that WebSocket connections over port 80 and 443 wlll have traffic patterns that are substantially different than normal HTTP patterns and how this might impact existing infrastructure is probably worthwhile but I don't think most of your note is helpful or serves much purpose (except as a passive aggressive way to express an opinion that the current WebSocket protocol is fatally flawed). Just one example: convoluted and inefficient. A simple 4-byte running XOR hash is convoluted? Certainly it's slightly more complicated than ... Wild guess: back when that text was written, the exchange was more complex than it is now, right? ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Who raised the bar? [Conclusion of the last call on draft-housley-two-maturity-levels]
On 2011-09-07 00:01, Brian E Carpenter wrote: On 2011-09-07 09:35, Ted Hardie wrote: ... My personal opinion for some time has been that we ought to recognize that the previous PS moved into WG draft years ago and that anything named an RFC should be recognized as something that market will consider a standard. And who raised the bar? It wasn't the IESG, it was the market, and more specifically the product managers and IT managers who adopted RFC conformance as their criterion. I'm a bit fed up with the IESG being blamed for this, rather than being congratulated on adapting to it. ... Well, if that's really what happened, then draft-housley-two-maturity-levels seems to solve the wrong problem. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [websec] Last Call: draft-ietf-websec-origin-04.txt (The Web Origin Concept) to Proposed Standard
On 2011-09-03 21:13, Adam Barth wrote: On Fri, Sep 2, 2011 at 12:38 PM, Roy T. Fieldingfield...@gbiv.com wrote: On Aug 23, 2011, at 2:19 PM, The IESG wrote: The IESG has received a request from the Web Security WG (websec) to consider the following document: - 'The Web Origin Concept' draft-ietf-websec-origin-04.txt as a Proposed Standard Sec 2.2: the definition of OWS includes a mistake that I just fixed in httpbis. OWS= *( [ obs-fold ] WSP ) ; optional whitespace obs-fold = CRLF should be OWS= *( HTAB / SP / obs-fold ) ; optional whitespace obs-fold = CRLF ( HTAB / SP ) ; obsolete line folding The problem isn't in OWS itself -- the above are equivalent. It is the definition of obs-fold that is wrong because it stands for the obsolete line folding allowed by RFC2616 (RFC822, etc.). A CRLF alone is not an obs-fold, so optimizing the ABNF in that way was wrong in httpbis. Likewise, I recommend replacing WSP with its equivalent ( HTAB / SP ) because the name is misleading and is only used in this one section. This text is intended to match the text from HTTPbis. The most recently published HTTPbis documents still contain the old construction: http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-16#section-1.2.2 Is there some way to see the as-yet-unpublished version with the updated text so I can make sure to get it exactly right? http://trac.tools.ietf.org/wg/httpbis/trac/browser/draft-ietf-httpbis/latest/p1-messaging.html But then, this is still work-in-progress. OTOH, perhaps a simpler change is in order. The above definitions are only used once in the document (Section 7.1). Furthermore, since we are defining a new header field (and not all header fields), we can be more proscriptive in 7.1 and remove the section above. In 7.1, instead of origin = Origin: OWS origin-list-or-null OWS define it as origin = Origin: [ SP ] origin-list-or-null and then most of 2.2 can be removed. Is there some advantage in doing that? It seems better to define this header in the same way we define all the other headers. If we do something different here, we run the risk of confusing folks into thinking that it requires some sort of different generation or parsing than everything else. The best way to do it (as Roy agreed as well) is just to define the ABNF for the field-value. ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IESG note?, was: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Hi, I believe that almost everything Roy says below is non-controversial; if we can tune the language to be less offensive it might fit well into the Introduction (and not require an IESG Note to get into the document). Best regards, Julian On 2011-09-01 21:55, Roy T. Fielding wrote: I sent this originally in March, before the last call, but I see that it still applies for draft-ietf-hybi-thewebsocketprotocol-13. If draft-ietf-hybi-thewebsocketprotocol-13 is approved, please add an IESG note to the effect of: = The WebSocket protocol is designed with an assumption that TCP port 80 or 443 will be used for the sake of tunneling raw socket exchanges over HTTP. The result is a convoluted and inefficient exchange of hashed data for the sake of bypassing intermediaries that may be routing, authenticating, filtering, or verifying traffic on those ports. The sole reason for using ports 80 and 443, and hence requiring the hashed data exchange, is because many organizations use TCP port blocking at firewalls to prevent unexpected network traffic, but allow the HTTP ports to remain open because they are expected to be used for normal Web request traffic. WebSocket deliberately bypasses network management constraints in order to enable Web application developers to send arbitrary data though a trusted port. Naturally, the WebSocket protocol does not have the same network characteristics as HTTP. The messages exchanged are likely to be smaller, more interactive, and delivered asynchronously over a long-lived connection. Unfortunately, those are the same characteristics of typical denial-of-service attacks over HTTP. Organizations deploying WebSockets should be aware that existing network equipment or software monitoring on those ports may need to be updated or replaced. = Cheers, Roy T. Fieldinghttp://roy.gbiv.com/ Begin forwarded message: From: Roy T. Fieldingfield...@gbiv.com Date: March 29, 2011 5:23:33 AM PDT To: Server-Initiated HTTPh...@ietf.org Cc: i...@iesg.org Subject: reuse of port 80/443 in hybi I am finding it difficult to participate in hybi in any meaningful way due to the very poor assumption that websockets traffic should use the same ports as Web traffic. Apparently, this decision was made on the basis of hums at an in-person WG meeting and the chairs believe it to be consensus (and thus quash any discussion that has apparent consensus due to the extent to which people keep bringing up old issues). It might even make some sense, given the name of this working group. Unfortunately, it is a fatal error. The rest of the protocol discussion is predicated on it, and enormously complex, for the sole reason of that initial error in design. More the pity. It assumes that the network infrastructure that currently monitors and balances traffic over 80/443 is going to instantly adapt to TCP-over-HTTP, as opposed to treating it like a denial of service attack. Browsers are fully capable of opening up new ports in firewalls simply by concerted use of open standards. Many other applications do so without this painful corruption of existing protocols. Yes, it takes time (but not as much time as one would think). Yes, there will be some companies that forcibly block some ports, just like there are some companies that forcibly block HTTP sites like facebook.com. That is their right. If the protocol is safe to use, it will be deployable over time. If not, then it shouldn't make the Web situation worse by increasing the amount of packet filtering at firewalls. So, I don't think the hybi work is worth continuing. The rest of the protocol decisions simply don't matter -- any of the already deployed proprietary hacks are better by default because they are no worse than hybi and don't have the imprimatur of the IETF. I'd rather develop a protocol that works with network administration rather than against it. I only ask that an IESG note be added to the final specification to the effect that this protocol knowingly misuses the Internet for the sake of bypassing organizational security. Be honest and let the admins make their own decisions. Cheers, Roy T. Fieldinghttp://roy.gbiv.com/ ___ hybi mailing list h...@ietf.org https://www.ietf.org/mailman/listinfo/hybi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG note?, was: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On 2011-09-03 12:54, Julian Reschke wrote: Hi, I believe that almost everything Roy says below is non-controversial; if we can tune the language to be less offensive it might fit well into the Introduction (and not require an IESG Note to get into the document). Best regards, Julian ... Like that...: The WebSocket protocol is designed with an assumption that TCP port 80 or 443 will be used for the sake of tunneling raw socket exchanges over HTTP. The result is a convoluted and inefficient exchange of hashed data for the sake of bypassing s/convoluted and inefficient/complex/ intermediaries that may be routing, authenticating, filtering, or verifying traffic on those ports. The sole reason for using s/sole// ports 80 and 443, and hence requiring the hashed data exchange, is because many organizations use TCP port blocking at firewalls to prevent unexpected network traffic, but allow the HTTP ports to remain open because they are expected to be used for normal Web request traffic. WebSocket deliberately bypasses network management constraints in order to enable Web application developers to send arbitrary data though a trusted port. Naturally, the WebSocket protocol does not have the same network characteristics as HTTP. The messages exchanged are likely to be smaller, more interactive, and delivered asynchronously over a long-lived connection. Unfortunately, those are the same characteristics of typical denial-of-service attacks over HTTP. Organizations deploying WebSockets should be aware that existing network equipment or software monitoring on those ports may need to be updated or replaced. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [websec] Last Call: draft-ietf-websec-origin-04.txt (The Web Origin Concept) to Proposed Standard
On 2011-09-02 12:20, Adam Barth wrote: I replied to Julian's message on a W3C list. Julian, is there more discussion you'd like to have about these points? ... Well, as discussed, the syntax of the Origin header makes it hard to detect errors which happen when multiple instances get folded into one; see http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#considerations.for.creating.header.fields -- but I fear it's too late to fix this? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Limitations in RFC Errata mechanism
On 2011-08-31 06:05, Mykyta Yevstifeyev wrote: ... Well, a reasonable argument. At Appendix A of draft-rfc-editor-errata-process-02 (http://tools.ietf.org/html/draft-rfc-editor-errata-process-02#appendix-A) I found a proposal from Brian Carpenter to point to errata list in the RFC itself, probably in Status of this Memo section. So this may be a solution. ... Status of this Memo already has a link to http://www.rfc-editor.org/info/rfc. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [websec] Last Call: draft-ietf-websec-origin-04.txt (The Web Origin Concept) to Proposed Standard
Below a few late comments.. 6. Serializing Origins - It really really seems that the two algorithms need to be swapped (the first one converts to ASCII, but the second does not). - Also, I'd prefer a declarative definition. 7. The HTTP Origin header - header *field* - the syntax doesn't allow multiple header fields, and the prose says clients MUST NOT generate them; what is the recipient supposed to do when it get's multiple instances anyway? Is the default approach (ignoring them all) good enough? Do we need to warn recipients so that they check? 11. References - the WEBSOCKETS reference should be updated (if a new draft is produced) Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Working groups and mailing list
On 2011-08-04 16:12, Worley, Dale R (Dale) wrote: From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Bill McQuillan [mcqui...@pobox.com] Perhaps it could be included in the ID-Announce message. In a lot of situations, the I-D submission tool knows the name of the relevant working group and could include its mailing list address in the announcement automatically. ... ...which of course does only help those readers who get to the ID via the announcement. In my experience, many ID authors actually forget to consider where to send feedback. Thus making this something to be checked upon ID submission (maybe with a way to opt-out) might be helpful. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Working groups and mailing list
On 2011-08-04 09:11, Bill McQuillan wrote: On Wed, 2011-08-03, Hector Santos wrote: I would like to propose that new I-D submissions include information about the existence of a Working Group, if any, and/or discussion group list address, if any, for to join and participate in the development of the I-D or simply to follow it. I think I have read some I-D that including this useful information, but most do not. Its one the first things I look for. I was going to suggest the same for an RFC, but it could be the WG was closed down by this time. Just a thought if it makes sense. +100 Perhaps it could be included in the ID-Announce message. +1 This should be mandatory in IDs. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Working groups and mailing list
On 2011-08-04 16:11, Worley, Dale R (Dale) wrote: From: Hector Santos I would like to propose that new I-D submissions include information about the existence of a Working Group, if any, and/or discussion group list address, if any, for to join and participate in the development of the I-D or simply to follow it. We already have mechanisms like this in place. Most I-Ds include the relevant WG in their name, and the extremely popular XML2RFC format has aworkgroup element for specifying the relevant WG. And the I-D submission tool checks that field. (I just got bitten by that.) The Since when does the ID submission tool check the XML??? XML2RFC tool carries theworkgroup value into the page headers of the text form (at least in some circumstances). Once one knows the WG name, one can go through www.ietf.org to find the information about the WG, including its mailing list. (Though one has to know some lore to do this successfully.) Indeed. ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
HTTP header field and upgrade token definitions, was: Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On 2011-07-11 16:02, The IESG wrote: ... This is a set of comments on how the specification defines new HTTP header fields and the upgrade token. 1) In the IANA considerations section, please group subsections by registrations and new registries. 2) Specification document(s) should actually point to the part of the spec that *specifies* the thing being registered. Just saying RFC or this document wastes the reader's time. 3) That being said, the header field registrations each contain a paragraph of prose explaining the header field. *Is* this the specification of the header, or does it only summarize more information from somewhere else? If so, from where? 4) Each header field definition needs to say what the header means in general, and what the syntax is (the latter can be either prose or ABNF, but ABNF would be preferred). It's not sufficient to describe it as part of a Websocket-specific algorithm - what's needed is a statement about what the header means on an HTTP message in general (and yes, saying it's only allowed in this or that context, and that it's meaningless otherwise would be ok). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Internet Draft Final Submission Cut-Off Today
On 2011-07-11 16:50, Internet-Drafts Administrator wrote: This is a reminder that the Internet Draft Final Submission (version -01 and up) cut-off is today, July 11, 2011. All Final Version (-01 and up) submissions are due by 17:00 PT (00:00 UTC). ... Out of curiosity - why do we still see new drafts coming out, even -00 ones? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On 2011-07-11 16:02, The IESG wrote: .. I believe Section 11 (IANA Considerations) should be grouped to into URI scheme registrations, HTTP header field registrations, and new registries. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On 2011-07-12 06:40, Mykyta Yevstifeyev wrote: ... Throughout the document: _This section is non-normative._ are quite unusual. Such statements occur at the beginning of Introduction, which is meant to be nob-normative a priori, its subsections, and Section 4.7, Examples. These sections, IMO, doesn't need to be additionally marked as non-normative. ... +1 Section 3. I propose to rewrite the first paragraph as follows: This specification defines two URI schemes for WebSocket protocol - 'ws' and 'wss'. Their syntax is defined below using ABNF [RFC5234] in thews-uri andwss-uri, respectively: ws-uri = ws: // host [ : port ] path-abempty [ ? query ] wss-uri = wss: // host [ : port ] path-abempty [ ? query ] where thehost,port,path-abempty andquery rules are defined in RFC 3986 [RFC3986]. Rationale: (1) The first paragraph gets clearer. (2) ABNF is changed not ot use pros-vals (RFC 5234) (3) s/path/path-abempty/ to directly import it from RFC 3986 (4) Several editorial issues fixed. -10 Granted, it doesn't use prose values anymore, but then it get's incomplete. I believe putting references to ABNF productions from other specs into prose values is absolutely the right thing to do (as opposed to just mention them in prose). Section 5.2.2, bullet 3, sub-bullet 4. When defining the ABNF for a header, the header name should be included in it as well. So the first line should be: ... Why? Section 9.1: extension-token = registered-token / private-use-token If you want RFC 2616 ABNF, this should be changed to: ... yes. extension-token = registered-token | private-use-token Ibid: Sec-WebSocket-Extensions: bar; baz=2 is exactly equivalent to Sec-WebSocket-Extensions: foo, bar; baz=2 These two examples don't match the aforementioned ABNF; the space before baz=2 should be removed. ... They do, as the RFC 2616 ABNF allows implied Linear Whitespace. That being said, it might be a good idea to revisit the choice of syntax, or at least to clarify the LWS situation. In ABNF terms using the terminals from the URI specifications: [RFC5234] [RFC3986] ws : hier-part [ ? query ] This isn't what you described in Section 3. hier-part includes the userinfo part, which shouldn't be present in WebSocket URIs. This ABNF should be fixed to match one in Section 3. ...or removed. Why are there two? Thepath [RFC3986] andquery components form the resource name sent to the server to identify the kind of service desired. Other components have the meanings described in RFC3986. If you adopt my proposal to Section 3, this should be fixed in the same way. References. RFC References here mean (from RFC 4395): References. Include full citations for all referenced documents. Registration templates for provisional registration may be included in an Internet Draft; when the documents expire or are approved for publication as an RFC, the registration will be updated. So this field should refer to Section 14 of the draft. Section 14 of this document. Section 11.2: the same applies. Section 11.12: Version Number | Reference -++-+- | 0 + draft-ietf-hybi-thewebsocketprotocol-00 | -++-+- [ . . . ] -++-+- | 9 + draft-ietf-hybi-thewebsocketprotocol-09 | -++-+- ... This is indeed fishy and I would be really surprised if IESG and RFC Editor let this pass. If 0..9 can't be reassigned then let's just state they are reserved. ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On 2011-07-12 09:48, Iñaki Baz Castillo wrote: 2011/7/12 Mykyta Yevstifeyevevniki...@gmail.com: Sec-WebSocket-Extensions: bar; baz=2 is exactly equivalent to Sec-WebSocket-Extensions: foo, bar; baz=2 These two examples don't match the aforementioned ABNF; the space before baz=2 should be removed. Hi, are you sure of that? In SIP protocol (which inherits from HTTP grammar) a header parameter (;foo=lalala) can contain spaces anywhere (before/after the ;, before/after the =). So something like: Sec-WebSocket-Extensions: foo , bar ; baz = 2 is valid. However it's not clear for me wheter in this example baz=2 is a header param or a param just for the value bar. In the last case it would mean a specific header syntax, so spaces could be not allowed. Could you please point to the ABNF grammar you meant? According to http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-9.1 it's a parameter of bar. That being said, I'm not happy with extension-param = token [ = token ] In HTTP header fields, parameters usually support both token and quoted-string form. Making this special means that existing header field parser code can't be easily re-used. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On 2011-07-12 10:23, Iñaki Baz Castillo wrote: 2011/7/12 Julian Reschkejulian.resc...@gmx.de: That being said, I'm not happy with extension-param = token [ = token ] In HTTP header fields, parameters usually support both token and quoted-string form. Right. Making this special means that existing header field parser code can't be easily re-used. Well, not exaclty as any parser supporting tokens and quoted-strings would also parse just tokens :) But if they *are* re-used, those recipients will accept quoted-strings as well (thus accepting invalid header fields). This could be harmless, or it could cause them to be used in practice, forcing other recipients to accept them as well. ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On 2011-07-12 11:09, Mykyta Yevstifeyev wrote: ... Section 5.2.2, bullet 3, sub-bullet 4. When defining the ABNF for a header, the header name should be included in it as well. So the first line should be: ... Why? There is the following formulation: The 'Foo' headers takes the form of foo-header ABNF rules below: foo-header = *(APHA/DIGIT) It should say: The 'Foo' header field's value takes the form... will result in the message headers like: Upgrade: TLS/1.2 Connection: Upgrade gfr134 and gfr134 will be the 'Foo' header. foo-header = Foo: *(APHA/DIGIT) will result in valid: Upgrade: TLS/1.2 Connection: Upgrade Foo: gfr134 See also eg. RFC 3282, RFC 2616. Have a look at the HTTPbis drafts. [ . . . ] That being said, it might be a good idea to revisit the choice of syntax, or at least to clarify the LWS situation. The document may reference the httpbis-p1 where the n#mrule extension will be described for valid ABNF. See http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-15#section-1.2.1 It could, but my guess is that HyBi doesn't want to wait for HTTPbis. ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Hi, this document has an informative reference to an unstable document at http://dev.w3.org/html5/websockets/. It should be replaced by a reference to the actual W3C WG's Working Draft: http://www.w3.org/TR/websockets/ (and potentially marked work in progress). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: reading drafts on an ipad
On 2011-07-08 21:10, Behcet Sarikaya wrote: I saw xml2rfc now has the option to convert to epub, which would make it easy to read drafts on the iPad and other mobile devices, but unfortunately when I tried to convert a draft it didn't work. Same here. It gives a bunch of error messages. Can someone please report it to xml2rfc mailing list? ... My own implementation is available here: http://greenbytes.de/tech/webdav/rfc2629xslt.zip. See http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#output.epub for installation requirements and instructions. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why ask for IETF Consensus on a WG document?
On 2011-06-24 20:27, Martin Rex wrote: ... Yes, I know that this is currently not easy for the one doing the write-up. Maybe this could be simplified by the IETF Mailing List exploder to _first_ put a message in the mailing list archive, obtain a URL into the archive for it and then send out the message _with_ that URL of the archived message out to the mailing list recipients. ... X-Archived-At? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC production center XML format usage, was: [IAOC] xml2rfc and legal services RFPs
On 2011-02-23 11:09, Julian Reschke wrote: ... I just realized that I have an archive of XML versions of RFCs in AUTH48 state; so I *can* report the percentage of XML versions since ~RFC5000. Note that these may be inaccurate (for instance, not all RFC numbers get assigned, right?); it just observes how much XML files ended up in AUTH48. Here are the numbers: RFC5000 - RFC5099: 41 RFC5100 - RFC5199: 44 RFC5200 - RFC5299: 47 RFC5300 - RFC5399: 48 RFC5400 - RFC5499: 64 RFC5500 - RFC5599: 59 RFC5600 - RFC5699: 58 RFC5700 - RFC5799: 64 RFC5800 - RFC5899: 63 RFC5900 - RFC5999: 68 RFC6000 - RFC6099: 69 ... Updated stats, just in time before the next meeting: RFC5000 - RFC5099: 41 RFC5100 - RFC5199: 44 RFC5200 - RFC5299: 47 RFC5300 - RFC5399: 48 RFC5400 - RFC5499: 64 RFC5500 - RFC5599: 59 RFC5600 - RFC5699: 58 RFC5700 - RFC5799: 64 RFC5800 - RFC5899: 63 RFC5900 - RFC5999: 68 RFC6000 - RFC6099: 70 RFC6100 - RFC6199: 56 RFC6200 - RFC6299: 77 ...so a drop in 6100..6199 (I wonder why?) and a all-time high in 6200..6299. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why ask for IETF Consensus on a WG document?
On 2011-06-24 20:55, Martin Rex wrote: Julian Reschke wrote: On 2011-06-24 20:27, Martin Rex wrote: ... Yes, I know that this is currently not easy for the one doing the write-up. Maybe this could be simplified by the IETF Mailing List exploder to _first_ put a message in the mailing list archive, obtain a URL into the archive for it and then send out the message _with_ that URL of the archived message out to the mailing list recipients. ... X-Archived-At? rather not there. Considering the sheer number of header lines of the averager mailing list email that hits my mailbox, and considering how difficult it is to get that junkyard visualized in some MUAs, I personally would prefer a modification of the automatically added message signature. The IETF mailing list exploder already automatically tacks a signature to every redistributed message with an indirect URL to the haystack i.e. the URL for the mailing list subscription page that itself contains an URL to the mailing list archive. potential solutions: - add a 4th line identifying the needle in the haystack. (bandwith-conservative) - replace the current indirect URL to the haystack (3rd line) with the direct message URL (needle URL) and add a back-reference to the mailing list subscription page to the top of the message/needle visualization page. WFM. Or make the archive URI a predictable function of the message ID, just like the W3C mailing list servers do. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
On 2011-06-17 06:01, Barry Leiba wrote: More substantively, I fail to understand how this specification proposes to create a class of reserved about: URIs when the about: scheme seems to be internal information to an application. I think the Security Considerations section doesn't address any of that, and probably ought to, particularly in light of the proposal to add text that users ought not to depend on standard behaviour. Yes... I'm actually very confused about the point of this document. It's documenting a URI scheme that's used ONLY internally, and, therefore, has no interoperability requirements. As best I can tell, the issue here is to let browser makers know what other browsers do, so that maybe new browsers will decide to do the same things. That's fine, and that helps users have a consistent experience across browsers. But it strikes me as Informational, not Standards Track. MUSTs and MUST NOTs seem completely out of place here, to me. If different browsers exhibit different behaviour with the same about: URI, that's as it is, and the variations should be documented. Developers of new browsers will have to decide which older browsers to emulate. But none of this actually speaks to interoperability among browsers or web servers or applications or ... The reason this whole activity is started is... http://www.w3.org/TR/2011/WD-html5-20110525/syntax.html#the-doctype which defines about:legacy-compat for which interoperable behavior is required from browsers. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
On 2011-06-17 06:37, Murray S. Kucherawy wrote: ... I suppose adding it as an IANA-registered scheme, referencing something that's Informational, is a reasonable way for a new browser implementer to be reminded that support for such a scheme is common and probably expected. ... Optimally, we had a strategy by which we can reserve certain scheme names (*), although they aren't really interoperable nor have a proper spec. Best regards, Julian (*) about, chrome, itms, ical, and probably many more... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
On 2011-06-17 06:32, Boris Zbarsky wrote: ... and because the normalization is not defined in the spec. Normalization is defined in RFC 3986. Browsers don't actually implement RFC 3986 in practice because it's not compatible with web content, last I checked Pretending like they do doesn't seem to be productive. ... It would be very helpful for the IRI WG if browser vendors actually reported what this incompatibility is; and whether UAs indeed agree on what the right thing to do is. So far I'm aware of certain kinds of preprocessing, and workarounds for specific schemes like data and file, but that's it... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
On 2011-06-16 10:59, Lachlan Hunt wrote: On 2011-06-15 17:59, Boris Zbarsky wrote: On 6/15/11 5:07 AM, Mykyta Yevstifeyev wrote: The point of this comment is to propose abandoning normalization of 'about' URIs because of some ad hoc behavior of an only application - Gecko. No, it's to propose abandoning normalization because it's not necessarily compatible with existing deployed uses of about:, not clearly compatible with the web security model, and because the normalization is not defined in the spec. The Gecko behavior is just an illustration of the first point. The purpose of our draft is to give a stable specification of the scheme Yes, this is fine. and normalize all existing types of behavior with regard to handling 'about' URIs. It will be easier for Gecko to change its behavior rather than for other apps to do this. Mykyta, we do need to make this spec document reality, particularly where implementations are unwilling to make changes. If it doesn't do that, then the spec is useless. I will be reviewing the options and look into exactly how other browsers handle these cases, and make appropriate changes to the spec. On the other hand, you're trying to define a URI scheme. If it's handling conflicts with the base URI spec, that's a bug. Period. You may *document* that some UAs have this bug, but you can't change it to be not a bug. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
