On 23/10/2012 21:07, David Kessens wrote:
> Doug,
>
> On Tue, Oct 23, 2012 at 12:26:58PM -0700, Doug Barton wrote:
>> You're not proposing a change in procedure. You're proposing to ignore
>> one.
>
> No procedure is ignored.
>
> BCP 101 does not define the rules for declaring a position vacant
On Tue, Oct 23, 2012 at 11:32:52AM -0700,
IESG Secretary wrote
a message of 7 lines which said:
> The Address Resolution for Massive numbers of hosts in the Data
> center (armd) working group in the Operations and Management Area
> has concluded.
Its charter is far from completed and I do not
Ted, Ian,
Un-marked context shifts are
likely, and likely to be bad. Avoiding them by picking a new term is
both easy and appropriate.
FWIW, I agree with Ted's advice above.
My personal opinion, as always,
Mine too.
Jari
On 23/10/2012 00:32, Mark Nottingham wrote:
...
> The underlying point that people seem to be making is that there's legitimate
> need for URIs to be a separate concept from "strings that will become URIs."
> By collapsing them into one thing, you're doing those folks a disservice.
> Browser im
On 10/24/2012 11:36 AM, Jari Arkko wrote:
> Ted, Ian,
>
>> Un-marked context shifts are
>> likely, and likely to be bad. Avoiding them by picking a new term is
>> both easy and appropriate.
>
> FWIW, I agree with Ted's advice above.
Further to that, some guy's fine tool [1] says that
RFC 3986
Bob wrote:
> Having his position declared vacant ...
How long has it been since the last time he attended an IAOC or IETF meeting,
or responded to an e-mail addressed directly to him?
We have processes that involve timers (viz. I-Ds expire after 6 months), and so
I am thinking we should discus
Stephane:
> On Thu, Oct 11, 2012 at 07:09:22AM -0700,
> IAB Chair wrote
> a message of 155 lines which said:
>
>> This is an IETF-wide Call for Comment on 'Affirmation of the Modern
>> Paradigm for Standards'.
>
> What's the point of this Call for Comment? Was there any chance that
> the text
On Wed, Oct 24, 2012 at 09:18:38AM -0400,
Russ Housley wrote
a message of 27 lines which said:
> The document captures the affirmation that took place on 29 August
> 2012. The document needs to contain the words that were affirmed.
> Any changes are a future activity, not associated with this
And now there seems to be another unannounced change, in that in
addition to the usual announcement format e-mails, there may also be, or
may not be, the appearance seems random, of
Subject: New Version Notification -
e-mails. This may or may not be an improvement, depending on how long
it takes
put bluntly, we all know the mail tools we're using to process these mails, and
the mails could be a damn sight more tractable for tools than they are.
ever tried sorting drafts by subject line?
that old draft-random-group-something-KEYWORD-version is really suckful for
something as basic as .
On Wed, 24 Oct 2012, Brian E Carpenter wrote:
> Agreed. It could be used for that, but I don't see it as required.
> We aren't dealing with alleged misbehaviour.
Where I come from failure to fulfill the duties of the position is
misbehaviour. I think it would be serious lack of respect for Mar
Hi Tom,
On 10/24/2012 09:28 AM, t.p. wrote:
And now there seems to be another unannounced change, in that in
addition to the usual announcement format e-mails, there may also be, or
may not be, the appearance seems random, of
Not so random. I noticed that the "New Version Notification" mails a
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 to do Web Sockets again, I wou
It should be quite clear to everyone that the horse is quite dead at this
point. Any further beating is entirely unnecessary. So let's wrap it up
with this: the whatwg's spec language around urls has the potential to
cause confusion among implementers, so please consider reworking that
language to
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 working group to get their act together and fix the URL mess.
> >>
+1
On 10/23/12 2:32 PM, James M Snell wrote:
> It should be quite clear to everyone that the horse is quite dead at
> this point. Any further beating is entirely unnecessary. So let's wrap
> it up with this: the whatwg's spec language around urls has the
> potential to cause confusion among implem
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 you insist on 'fixing STD 66'?
What is the reason you are not willing to reframe the problem to 'fixing
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 you insist on 'fixing STD 66'?
>
> What is th
On Tue, 23 Oct 2012, Ted Hardie wrote:
>
> Unless you get buy-in from the community that produced RFC 3986 and RFC
> 3987, the production of this document *will* result in a fork, and that
> is damaging to the Internet.
I'm trying to work with y'all to see how we can update these specs instead
On Oct 24, 2012, at 12:43 AM, Ian Hickson wrote:
> 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:
Jan wrote:
Help me, I am just not getting it:
> Why do you insist on 'fixing STD 66'?
> What is the reason you are not willing to reframe the problem to 'fixing
> how we get from the provided string -the input to the reference
> construction process- to a STD-66-valid result'?
> To me this is real
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)\._.,--,'``.fL
http://ln.h
On Wed, 24 Oct 2012, Christophe Lauret wrote:
>
> As a Web developer who's had to write code multiple times to handle URIs
> in very different contexts, I actually *like* the constraints in STD 66,
> there are many instances where it is simpler to assume that the error
> handling has been done
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 faster when implementors h
> From: Ian Hickson [mailto:i...@hixie.ch]
> I think we can agree that the error handling should be, at the option
> of the software developer, either to handle the input as defined by the
> spec's algorithms, or to abort and not handle the input at all.
Currently, I don't think url.spec.whatwg.or
Hello Lou,
> >
> > We think you are correct about the Path message.
> > But Resv messages are different. The Resv messages are sent hop-
> > by-hop. The destination is not the remote PE but the unicast
> > address of a previous RSVP hop when a PE send out a Resv message.
> >
> > Therefor, there
On Tue, Oct 23, 2012 at 05:47:48PM -0700, Doug Barton wrote:
>
> On 10/23/2012 2:32 PM, John Leslie wrote:
> > In other organizations, I have lived through longish periods of
> > uncertainty about the exact status of an individual, and I no longer
> > find it scary.
>
> I tend to agree, which is
On Tue, Oct 23, 2012 at 4:51 PM, Ian Hickson wrote:
> On Wed, 24 Oct 2012, Christophe Lauret wrote:
>>
>> As a Web developer who's had to write code multiple times to handle URIs
>> in very different contexts, I actually *like* the constraints in STD 66,
>> there are many instances where it is sim
David Sheets scripsit:
> Anne's current draft increases the space of valid addresses. This
> isn't obvious as Anne's draft lacks a grammar and URI component
> alphabets. You support Anne's draft and its philosophy, therefore you
> are saying the space of valid addresses should be expanded.
Before
On Tue, Oct 23, 2012 at 8:59 PM, John Cowan wrote:
> David Sheets scripsit:
>
>> Anne's current draft increases the space of valid addresses. This
>> isn't obvious as Anne's draft lacks a grammar and URI component
>> alphabets. You support Anne's draft and its philosophy, therefore you
>> are sayi
On Wed, 24 Oct 2012, Manger, James H wrote:
>
> Currently, I don't think url.spec.whatwg.org distinguishes between
> strings that are valid URLs and strings that can be interpreted as URLs
> by applying its standardised error handling. Consequently, error
> handling cannot be at the option of t
> On Wed, 24 Oct 2012, Manger, James H wrote:
> >
> > Currently, I don't think url.spec.whatwg.org distinguishes between
> > strings that are valid URLs and strings that can be interpreted as
> > URLs by applying its standardised error handling. Consequently, error
> > handling cannot be at the opt
On Wed, Oct 24, 2012 at 8:41 AM, Manger, James H
wrote:
> That is good to hear. There is no hint about this in the current
> text/outline. There is an "invalid" flag in the current text -- but that is
> for strings that are so broken no error handling can resurrect a URL. There
> is no mention
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?
>
> Do you mean the actual text, or the normative meaning of the text?
I ideally mean the actual t
--On Wednesday, October 24, 2012 11:39 +0100 Brian E Carpenter
wrote:
>
> On 23/10/2012 00:32, Mark Nottingham wrote:
> ...
>> The underlying point that people seem to be making is that
>> there's legitimate need for URIs to be a separate concept
>> from "strings that will become URIs." By col
On Oct 24, 2012, at 1:01 AM, Doug Barton wrote:
> I get what you're saying, but this is one of those times where (arguably
> for the better) we've created a difficult procedure that should be
> infrequently exercised. We should follow the procedure because it _is_
> the procedure. And then use the
Since a few people are asking questions that were answered in the original
email, here is a link to the mail that was sent to ietf-announce on October 22,
2012:
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=11277&tid=1351092666
I thought this would be helpful since it was only
> David Morris wrote:
>
> On Wed, 24 Oct 2012, Brian E Carpenter wrote:
>
> > Agreed. It could be used for that, but I don't see it as required.
> > We aren't dealing with alleged misbehaviour.
>
> Where I come from failure to fulfill the duties of the position is
misbehaviour.
My thoughts exac
On Oct 24, 2012, at 06:20, David Sheets wrote:
> WHATWGRL
Hey, call them EARLs. Error-tolerant web-Address Repairing Labels or whatever.
(Just not URLs, that term is already taken in the Web.)
Grüße, Carsten
The draft that proposes changes to the RFC3777/BCP10 to deal with vacancies is
now available.
http://tools.ietf.org/html/draft-ietf-genarea-bcp10upd-00
Bob
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Reply-to: internet-dra...@ietf.org
Subject: I-D ACTION:
On 10/23/12 2:52 PM, Jan Algermissen wrote:
> Then, how about going from 'fixing STD 66' to
>
> 'augmenting STD 66 with how we get from the provided string -the
> input to the reference construction process- to a valid URI'?
[ ... ]
> What matters is that nothing of the existing URI spec *change
>I agree with you that removing him would be the simplest approach, but I
>can see possible situations where NOT following the process could lead
>us into legal trouble.
Anyone can sue in the US for any reason, but this is silly.
The IAOC made extensive attempts to contact him in many ways, wit
On Wed, 24 Oct 2012, John Levine wrote:
> >I agree with you that removing him would be the simplest approach, but I
> >can see possible situations where NOT following the process could lead
> >us into legal trouble.
>
> Anyone can sue in the US for any reason, but this is silly.
>
> The IAOC
On 10/24/2012 5:49 AM, Margaret Wasserman wrote:
>
> On Oct 24, 2012, at 1:01 AM, Doug Barton wrote:
>> I get what you're saying, but this is one of those times where
>> (arguably for the better) we've created a difficult procedure that
>> should be infrequently exercised. We should follow the pro
>
> The draft that proposes changes to the RFC3777/BCP10 to deal with
> vacancies is now available.
>
> http://tools.ietf.org/html/draft-ietf-genarea-bcp10upd-00
>
>
Two comments:
1 (nit):
For vacancies due to death or resignation, no further action is
required, to declare the seat vacant.
On Oct 24, 2012, at 4:22 PM, Barry Leiba
wrote:
>
> 2:
>For vacancies due to uncontested, sustained absence, the IETF body
>making that determination will issue an Extended Last Call to the
>community.
>
> Where is "Extended Last Call" defined? There should be a citation thither,
>
> > Where is "Extended Last Call" defined? There should be a citation
> thither, or a definition here.
>
> RFC 2026 section 9.1
>
>The proposed variance must detail the problem perceived, explain the
>precise provision of this document which is causing the need for a
>variance, and t
I see several issues
a) To my reading RFC 3777 only deals with IAB and IESG membership
b) Neither this draft nor 3777 defines 'IETF body'
c) Consindering that someone would be a member until removed, and
assuming IAOC is meant to be considered an IETF body, 2/3 of
members approving c
>The legal issue raised by a previous reply that resonates with me is
>that someone unsatisfied with a business decision by the adjusted
>IAOC membership could sue based on documented process not being
>followed to appoint the membership.
Are you aware of any case law that suggests that any U.S. c
>
> a) To my reading RFC 3777 only deals with IAB and IESG membership
RFC 4071 (BCP 101) specifies use of the 3777 recall process for the IAOC.
> b) Neither this draft nor 3777 defines 'IETF body'
Simply making Section 3.1 say 'the IAB, IESG, or IAOC ("an IETF body")'
will take care of that.
On Wed, 24 Oct 2012, John Levine wrote:
> >The legal issue raised by a previous reply that resonates with me is
> >that someone unsatisfied with a business decision by the adjusted
> >IAOC membership could sue based on documented process not being
> >followed to appoint the membership.
>
> Are
David Morris wrote:
>
> John Levine wrote:
> >
> > >I agree with you that removing him would be the simplest approach, but I
> > >can see possible situations where NOT following the process could lead
> > >us into legal trouble.
> >
> > Anyone can sue in the US for any reason, but this is silly
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?
> >
> > Do you mean the actual text, or the n
On Oct 24, 2012, at 3:39 AM, Brian E Carpenter wrote:
> On 23/10/2012 00:32, Mark Nottingham wrote:
> ...
>> The underlying point that people seem to be making is that there's
>> legitimate need for URIs to be a separate concept from "strings that will
>> become URIs." By collapsing them into one
On Tue, 23 Oct 2012, 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 faster when implementors have to switch between specs
> just in the implementation
Doug Barton wrote:
>
> Andrew Sullivan wrote:
>>
>> Let me get this straight: for the sake of procedures that are clearly
>> designed to be hard to use,
>
> While I think that 3777 probably errs on the side of too hard to use,
> recalling someone from one of these positions _should_ be hard to do
In message , Margaret Wass
erman writes:
>
> On Oct 24, 2012, at 1:01 AM, Doug Barton wrote:
> > I get what you're saying, but this is one of those times where (arguably
> > for the better) we've created a difficult procedure that should be
> > infrequently exercised. We should follow the procedu
Randall Gellens wrote:
>> Warning: this message was generated by Apple Mail.
RG> But not using Format=Flowed.
RG> This reflects a misunderstanding of Format=Flowed. Properly
RG> generated F=F has lines of no more than 78 characters. One of
RG> the primary goals of F=F is g
Sabahattin Gucukoglu wrote:
SG> Let's clear up the confusion. I made two mistakes, firstly by
SG> calling this "F/F semantics" when what I mean is some sort of
SG> long-line-aware reflowing and quoting. We'll have to find a name
SG> for it. The other mistake was to call plain text plain text o
>But we don't have rules that say, "failure to attend for X period,
>without permission, will result in the position being declared
>vacant". I we did this would be simple. I don't think we have
>any choice from a proceedural point of view other than to start
>recall proceedings.
Having reread R
On Tue, Oct 23, 2012 at 10:05 PM, Ian Hickson wrote:
> On Wed, 24 Oct 2012, Manger, James H wrote:
>>
>> Currently, I don't think url.spec.whatwg.org distinguishes between
>> strings that are valid URLs and strings that can be interpreted as URLs
>> by applying its standardised error handling. Con
On Oct 25, 2012, at 1:25 AM, Martin Rex wrote:
> Doug Barton wrote:
>>
>> Andrew Sullivan wrote:
>>>
>>> Let me get this straight: for the sake of procedures that are clearly
>>> designed to be hard to use,
>>
>> While I think that 3777 probably errs on the side of too hard to use,
>> recallin
62 matches
Mail list logo
