On Wed, 24 Oct 2012, Jan Algermissen wrote:
> On Oct 24, 2012, at 1:47 AM, Ian Hickson wrote:
> > On Wed, 24 Oct 2012, Jan Algermissen wrote:
> >>
> >> What matters is that nothing of the existing URI spec *changes*.
> >>
> >> Can you agree on that?
s, technical data,
etc, and let the spec editor take all that into account and turn it into a
standard. Arguing about what precise alphabets are allowed and whether to
spec something using prose or production rules is just bikeshedding.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
On Tue, 23 Oct 2012, Ted Hardie wrote:
> On Tue, Oct 23, 2012 at 4:51 PM, Ian Hickson wrote:
> > Having multiple specs means an implementor has to refer to multiple
> > specs to implement one algorithm, which is not a way to get
> > interoperability. Bugs creep in much fas
dling errors, so defining those doesn't increase complexity either
(especially if such behaviour is left as optional, as discussed above.)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
On Wed, 24 Oct 2012, Jan Algermissen wrote:
>
> What matters is that nothing of the existing URI spec *changes*.
>
> Can you agree on that?
Do you mean the actual text, or the normative meaning of the text?
--
Ian Hickson U+1047E)\._.,--,&#x
k won't harm the Internet any more than
STD 66 already is. Might even help matters, if curl and wget both decide
to follow the WHATWGRLs spec (or whatever), instead of STD 66, and as a
result start interoperating.
$ curl 'http://example.com/a b' # fetches "/a b" from examp
On Tue, 23 Oct 2012, Jan Algermissen wrote:
> On Oct 23, 2012, at 11:34 PM, Ian Hickson wrote:
> >
> > Let's in fact try: Hi guys, we need to fix STD 66 because it doesn't
> > define error handling.
>
> Help me, I am just not getting it:
>
> Why do
On Tue, 23 Oct 2012, Ted Hardie wrote:
> On Mon, Oct 22, 2012 at 2:46 PM, 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 worki
On Tue, 23 Oct 2012, Julian Reschke wrote:
> 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
o browser vendors and authors
of software that interacts with the Web, e.g. Web search engine software
(GoogleBot), Web mirroring software (wget), etc, often run into it.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A
On Tue, 23 Oct 2012, Mark Nottingham wrote:
> On 23/10/2012, at 10:40 AM, Ian Hickson wrote:
> > On Tue, 23 Oct 2012, Mark Nottingham wrote:
> >>
> >> Don't much care about the venue, as long as there's *some*
> >> coordination / communication.
>
hat it's a good thing,
> > therefore, that I and others don't work at the IETF, but in that case
> > you shouldn't complain when we go and do stuff outside the IETF.
>
> Again, I'm not stuffed about the venue, and you can do what you like.
> However, when the *W3
ence is that the DNS implementor doesn't need to implement TCP,
he uses TCP (and UDP) and builds on it. And so on. Whereas here we're
talking about one thing, URLs, being specified in one place vs three.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
On Tue, 23 Oct 2012, Mark Nottingham wrote:
> On 23/10/2012, at 10:16 AM, Ian Hickson wrote:
> >
> > I can't speak for Anne, but having experienced the IETF via the hybi
> > work, my own opinion is that the main reason I wouldn't work with the
> > IETF is
On Tue, 23 Oct 2012, Mark Nottingham wrote:
> On 23/10/2012, at 9:35 AM, Ian Hickson wrote:
> >
> > Consensus isn't a value I hold highly, but review of Anne's work is
> > welcome.
> >
> > If the IETF community didn't want Anne to do this work,
t, suplanted by work at the WHATWG after failed attempts at
getting the specs and registries at the IETF/IANA into better shape:
http://encoding.spec.whatwg.org/
I spoke to Anne briefly and he pointed me to:
http://wiki.whatwg.org/wiki/IETF
...which gives a very brief synopsis of why
to do this work, then the IETF
community should have done it. Having not done it, having not even
understood that the problem exists, means the IETF has lost the
credibility it needs to claim that this is in the IETF's domain.
You don't get to claim authority over an area while at the sa
dy received and
> define references in HTML, including the algorithms for converting them
> into URI references (for DOM and network usage) and IRI references (for
> display).
As far as HTML goes, my plan is to remove all references to STD 6
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 mat
On Wed, 17 Oct 2012, 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 t
he willful violations are not limited
> to RFC 3986: the spec also mentions willful violations of RFC 2046, RFC
> 2616, RFC 2781, RFC 5322, EcmaScript, XPath, XSLT, and Unicode. Quite a
> list...
Yeah. Turns out we (the Web standards community) haven't been doing such a
great job of m
On Sun, 2 Aug 2009, Julian Reschke wrote:
> Ian Hickson wrote:
> > ...
> > Unless there are really strong use cases, I think that the anchor= attribute
> > should be dropped. In practice, implementations today ignore that attribute,
> > which would mean that, e.g., a r
form is defined (as requested above). But how
does the registry fit into the RelExtensions registry for HTML5? How
should they interact?
The "up", "first", "last", and "payment" types are woefully underdefined.
What is the expected UA behaviour when dis
23 matches
Mail list logo
