> On 08/05/2013 08:33, Ned Freed wrote:
> >> On 08/05/2013 03:28, John C Klensin wrote:
> >> ...
> I'll also point out that this has diddley-squat to do with
> formal verification processes. Again as Mark Anrdrews points
> out, we deployed something with a restriction that
> sub
Hi -
> From: "Brian E Carpenter"
> To: "Ned Freed"
> Cc: "John C Klensin" ; ;
>
> Sent: Tuesday, May 07, 2013 2:19 PM
> Subject: Re: Language editing
...
> You are correct if only considering the mail standards. I suspect
> that a serious
On 08/05/2013 08:33, Ned Freed wrote:
>> On 08/05/2013 03:28, John C Klensin wrote:
>> ...
I'll also point out that this has diddley-squat to do with
formal verification processes. Again as Mark Anrdrews points
out, we deployed something with a restriction that
subsequently turn
> On 08/05/2013 03:28, John C Klensin wrote:
> ...
> >> I'll also point out that this has diddley-squat to do with
> >> formal verification processes. Again as Mark Anrdrews points
> >> out, we deployed something with a restriction that
> >> subsequently turned out to be unnecessary, and now we're
On 08/05/2013 03:28, John C Klensin wrote:
...
>> I'll also point out that this has diddley-squat to do with
>> formal verification processes. Again as Mark Anrdrews points
>> out, we deployed something with a restriction that
>> subsequently turned out to be unnecessary, and now we're stuck
>> wit
--On Tuesday, May 07, 2013 08:08 -0700 Ned Freed
wrote:
>> Maybe things have changed, but, if one actually believes the
>> robustness principle, then, in the case Geoff cites, Exchange
>> is simply non-conforming -- not because the spec prohibits
>> rejecting on the basis of a fine distinction
> Maybe things have changed, but, if one actually believes the
> robustness principle, then, in the case Geoff cites, Exchange is
> simply non-conforming -- not because the spec prohibits
> rejecting on the basis of a fine distinction about IPv6 formats,
> but because doing so is unnecessary, incon
> Mark Andrews wrote:
> >
> > Apples mail client is broken [IPv6:2001:df9::4015:1430:8367:2073:5d0]
> > is not legal according to both RFC 5321 and RFC 2821 which is all
> > that applies here.
>I was until today unaware how strong the feelings are on this
> "one-or-more" vs. "two-or-more" iss
You missed the point RFC 5321 SMTP clients have to operate
with RFC 2821 SMTP servers when sending address literal in
the HELO/EHLO. Code doesn't magically get updated when the
spec is updated. It takes years for changes to trickle
through. The code has t
Mark Andrews wrote:
>
> Apples mail client is broken [IPv6:2001:df9::4015:1430:8367:2073:5d0]
> is not legal according to both RFC 5321 and RFC 2821 which is all
> that applies here.
I was until today unaware how strong the feelings are on this
"one-or-more" vs. "two-or-more" issue. I do not
In message <51881140.5070...@gmail.com>, Brian E Carpenter writes:
> On 07/05/2013 02:10, l.w...@surrey.ac.uk wrote:
> > http://labs.apnic.net/blabs/?p=309
> >
> > an excellent detective story on badly-written, poorly edited, standards
> > track RFCs leading to interop pro
> blems. Enjoy.
>
> I
--On Tuesday, May 07, 2013 08:23 +1200 Brian E Carpenter
wrote:
> On 07/05/2013 02:10, l.w...@surrey.ac.uk wrote:
>> http://labs.apnic.net/blabs/?p=309
>>
>> an excellent detective story on badly-written, poorly edited,
>> standards track RFCs leading to interop problems. Enjoy.
>
> I don't t
On 07/05/2013 02:10, l.w...@surrey.ac.uk wrote:
> http://labs.apnic.net/blabs/?p=309
>
> an excellent detective story on badly-written, poorly edited, standards track
> RFCs leading to interop problems. Enjoy.
I don't that is quite right. The problem in this case is not to do
with linguistic qua
> From: Brian E Carpenter
>
> On 04/05/2013 09:22, Yaron Sheffer wrote:
> > GEN-ART is a good example, but actual document editing is much more work
> > and arguably, less rewarding than a review. So I think this can only
> > succeed with professional (=paid) editors.
>
> I think I disagree, if
discussion.
From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of John C Klensin
[john-i...@jck.com]
Sent: 05 May 2013 19:32
To: Brian E Carpenter; Yaron Sheffer
Cc: ietf@ietf.org
Subject: Re: Language editing
--On Saturday, May 04, 2013 10:04
--On Saturday, May 04, 2013 10:04 +1200 Brian E Carpenter
wrote:
> On 04/05/2013 09:22, Yaron Sheffer wrote:
>> GEN-ART is a good example, but actual document editing is
>> much more work and arguably, less rewarding than a review. So
>> I think this can only succeed with professional (=paid)
>
On 5/3/13 3:04 PM, Brian E Carpenter wrote:
On 04/05/2013 09:22, Yaron Sheffer wrote:
GEN-ART is a good example, but actual document editing is much more work
and arguably, less rewarding than a review. So I think this can only
succeed with professional (=paid) editors.
I think I disagree, if w
On 04/05/2013 09:22, Yaron Sheffer wrote:
> GEN-ART is a good example, but actual document editing is much more work
> and arguably, less rewarding than a review. So I think this can only
> succeed with professional (=paid) editors.
I think I disagree, if we can find the knack of effective crowd-s
On 05/03/2013 02:22 PM, Yaron Sheffer wrote:
GEN-ART is a good example, but actual document editing is much more work
and arguably, less rewarding than a review. So I think this can only
succeed with professional (=paid) editors.
I'm not sure that's the right conclusion to draw.
In the past I
GEN-ART is a good example, but actual document editing is much more work
and arguably, less rewarding than a review. So I think this can only
succeed with professional (=paid) editors.
Thanks,
Yaron
On 05/02/2013 02:40 PM, Yaron Sheffer wrote:
I suggest that we budget for a number o
> From: Scott Brim
>
> My experience is that unless the editors have some background in
> protocols, this takes a surprising amount of effort, explaining it to
> them and catching _their_ mistaken assumptions (which can be subtle).
I'm told that the CCITT maintains a staff of technical writers.
On May 2, 2013, at 9:47 PM 5/2/13, Dave Crocker wrote:
> On 5/2/2013 4:13 PM, Peter Saint-Andre wrote:
>> Instead of imposing even more work on the RFC Editor team, I suggest
>> that you find someone in the WG, in your company, in the IETF
>> community (etc.) to help with the language issues. I
Original Message -
From: "TZI"
To: "t.p."
Cc: "Peter Saint-Andre" ; "Marc Petit-Huguenin"
; "Yaron Sheffer" ; "ietf"
Sent: Friday, May 03, 2013 9:37 AM
Subject: Re: Language editing
> We really do need a tool, the l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/2013 02:40 PM, Yaron Sheffer wrote:
> I suggest that we budget for a number of WG drafts per year (say,
> 20 IETF-wide) to go through professional, paid-for heavy-duty
> editing
My experience is that unless the editors have some background in
On May 3, 2013, at 4:24 AM, t.p. wrote:
> We really do need a tool, the like of which I was using 40 years ago
> when writing code, that allows patches to be applied independently and
> temporarily to see what it then looks like and if agreed that it looks
> good, incorporating them permanently in
> We really do need a tool, the like of which I was using 40 years ago
> when writing code, that allows patches to be applied independently
that's what pull requests (or gerrit) are about.
> and
> temporarily to see what it then looks like and if agreed that it looks
> good, incorporating them pe
- Original Message -
From: "Peter Saint-Andre"
To: "Marc Petit-Huguenin"
Cc: "Yaron Sheffer" ;
Sent: Friday, May 03, 2013 12:13 AM
>
> On 5/2/13 4:03 PM, Marc Petit-Huguenin wrote:
> > On 05/02/2013 02:40 PM, Yaron Sheffer wrote:
> > An alternative would be to have the RFC-editor doing c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/02/2013 06:41 PM, Carsten Bormann wrote:
> On May 3, 2013, at 01:13, Peter Saint-Andre wrote:
>
>> source control
>
> I don't think it has been emphasized enough how important that is from a
> document quality perspective.
>
> More importan
On May 2, 2013, at 9:47 PM, Dave Crocker wrote:
> If the community does not have enough interest in the work to write it well,
> it has bigger problems that won't be remedied by more RFC Editor effort...
Also worth considering is that if a document is hard to read, it is hard to
review, and hen
On May 2, 2013, at 9:41 PM, Carsten Bormann wrote:
> People who aren't aware of it should look at the httpbis github experiment.
> The pull request is a powerful model of WG collaboration.
Several authors in the dhc working group have been doing the same thing, to
good effect.
On 5/2/2013 4:13 PM, Peter Saint-Andre wrote:
Instead of imposing even more work on the RFC Editor team, I suggest
that you find someone in the WG, in your company, in the IETF
community (etc.) to help with the language issues. I did this recently
with a document in one of the WGs where I'm activ
On May 3, 2013, at 01:13, Peter Saint-Andre wrote:
> source control
I don't think it has been emphasized enough how important that is from a
document quality perspective.
More importantly for this discussion, it also somewhat mitigates the document
editor as a choking point.
People who aren'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/2/13 4:03 PM, Marc Petit-Huguenin wrote:
> On 05/02/2013 02:40 PM, Yaron Sheffer wrote:
>> As a non-native English speaker, but a language pedant
>> nonetheless, I can empathize with people who put Discusses on
>> badly written documents.
>
>> I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/02/2013 02:40 PM, Yaron Sheffer wrote:
> As a non-native English speaker, but a language pedant nonetheless, I can
> empathize with people who put Discusses on badly written documents.
>
> I suggest that we budget for a number of WG drafts pe
As a non-native English speaker, but a language pedant nonetheless, I
can empathize with people who put Discusses on badly written documents.
I suggest that we budget for a number of WG drafts per year (say, 20
IETF-wide) to go through professional, paid-for heavy-duty editing, with
these goal
35 matches
Mail list logo
