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]
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
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
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
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.
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
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
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
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
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
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?
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
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
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
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
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
), 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
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...
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
(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:
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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'
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
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
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
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,
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
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
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
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
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
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
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
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,
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
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
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
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
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.
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
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
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
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
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
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
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
1 - 100 of 455 matches
Mail list logo
