headers
Bruce Lilly | 9 May 20:11
Picon

Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt


> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Message Header for Indicating Sender Authentication Status
> 	Author(s)	: M. Kucherawy
> 	Filename	: draft-kucherawy-sender-auth-header-02.txt
> 	Pages		: 15
> 	Date		: 2005-5-5
> 	
> This memo defines a new message header for use with [MAIL] messages
>    to indicate the results of sender authentication efforts to mail user
>    agents (MUAs) in order to equip them to relay that information in a
>    convenient way to users.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-02.txt

Review of         draft-kucherawy-sender-auth-header-02      by B. Lilly

Internet-Drafts and RFCs are required to meet certain criteria: [R1.ID],
[R2.Instruct].  These can be checked by using the "idnits" tool:
[R3.idnits].  That tool noted the following regarding the document:

idnits 1.71 (02 May 2005)

draft-kucherawy-sender-auth-header-02.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :
(Continue reading)

Permalink | Reply | 35 comments |
headers
Frank Ellermann | 10 May 01:33
Picon
Picon

Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt


Bruce Lilly wrote:

> Review of draft-kucherawy-sender-auth-header-02 by B. Lilly

Is your review tool also available as Web form ?  Something
like proto-I-D in, death sentence (or whatever) out ?

The "idnits webservice" (and related tools like rfcdiff) does
not work from my POV, I get no output, only the "usage" page:

<http://ietf.levkowetz.com/tools/idnits/idnits.pyht>

>    [X] ABNF [R4.RFC2234]

Somewhat beside the point, but this draft doesn't contain the
string "2234" or "ABNF".  And if you check it anyway Scott H.
wants us to use the new 2234bis in the References.

>               20:0: error: Empty rule
>               22:0: error: Empty rule

>    Clearly, the "ABNF" is badly broken.

That's not helpful, so how should we reference terms defined
elsewhere ?  Especially terms defined NOWHERE in ABNF, as all
2045 or 2231 terms.  Sorry, but I'm getting _very_ angry if I
see this, it's a royal PITA, see also many USEFOR articles.

> However, the status as defined in BCP 9 should be:
(Continue reading)

Permalink | Reply | 34 comments |
headers
Bruce Lilly | 10 May 03:05
Picon

Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt


On Mon May 9 2005 19:33, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
>  
> > Review of draft-kucherawy-sender-auth-header-02 by B. Lilly
> 
> Is your review tool also available as Web form ?

No. It's a set of troff/nroff macros and template that can  be used
to generate a review document (or one could edit the text version).

> Something 
> like proto-I-D in, death sentence (or whatever) out ?

No, it requires human review.

> The "idnits webservice" (and related tools like rfcdiff) does
> not work from my POV, I get no output, only the "usage" page:
> 
> <http://ietf.levkowetz.com/tools/idnits/idnits.pyht>

I just run idnits locally.

> >    [X] ABNF [R4.RFC2234]
> 
> Somewhat beside the point, but this draft doesn't contain the
> string "2234" or "ABNF".

It should, since it uses ABNF.  Since one needs to understand
(Continue reading)

Permalink | Reply | 33 comments |
headers
Frank Ellermann | 10 May 10:50
Picon
Picon

Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt


Bruce Lilly wrote:

>> Scott H. wants us to use the new 2234bis in the References.

> A normative reference would hold up publication, as the 2234
> successor isn't yet a published RFC.

<http://mid.gmane.org/046F43A8D79C794FA4733814869CDF0749C9AF <at> dul1wnexmb01.vcorp.ad.vrsn.com>

It's not that I necessarily agree, but it's also not an issue
where I'd risk a debate with an AD if I care about the draft.

>> how should we reference terms defined elsewhere ?

> a) use a term defined elsewhere, including the source as a
>    normative reference.

Is this also possible for something like "token", where even
the source RfC 2045 offers no proper syntax, let alone ABNF ?

Serious question, I was surprised to find this trick in 3834,
where I guess that it must have passed your review (and we're
still discussing related 2045-issues in USEFOR).

> b) write the necessary ABNF. It's not rocket science.

For terms redefined by RfC 2231 I'd prefer rocket science ;->
Okay, no problem for Murray, he uses "token", not "parameter".
(Continue reading)

Permalink | Reply | 32 comments |
headers
Bruce Lilly | 10 May 17:41
Picon

Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt


On Tue May 10 2005 04:50, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> >> Scott H. wants us to use the new 2234bis in the References.
> 
> > A normative reference would hold up publication, as the 2234
> > successor isn't yet a published RFC.
> 
> <http://mid.gmane.org/046F43A8D79C794FA4733814869CDF0749C9AF <at> dul1wnexmb01.vcorp.ad.vrsn.com>
> 
> It's not that I necessarily agree, but it's also not an issue
> where I'd risk a debate with an AD if I care about the draft.

"Pay the AD now or pay the RFC Editor later".  The RFC Editor will
hold up publication as an RFC until all normative references are
published.  Expect a change in policy or delays in publication of
documents with ABNF.  Note that there are some serious problems
with the ABNF draft (admittedly also in 2234):
http://www1.ietf.org/mail-archive/web/ietf/current/msg34855.html
Further note that the ID-Checklist specifies a normative reference
to 2234, not an informative reference and not a reference to some
other document.

> >> how should we reference terms defined elsewhere ?
> 
> > a) use a term defined elsewhere, including the source as a
> >    normative reference.
>
(Continue reading)

Permalink | Reply | 31 comments |
headers
william(at)elan.net | 11 May 01:31

Review draft-leibzon-content-author-originator-00.txt


I'd like to request review of my recently published draft:
  http://www.ietf.org/internet-drafts/draft-leibzon-content-author-originator-00.txt
  http://www.elan.net/~william/emailsecurity/draft-leibzon-content-author-originator-00.html

The draft proposes two new header fields Content-Author and Content-Originator
for use with specific message data parts (note: 'message' is not limited 
to SMTP as HTTP transmission is considered valid message) and identification 
of the author of the data content and person responsible for originating 
transmission of the data part. Examples in the draft are good illustration
of what I mean.

I'd like to also receive comments as to the security considerations that 
should be mentioned (if any) as I do not believe my current text is 
sufficient or appropriate.

--

-- 
William Leibzon
Elan Networks
william <at> elan.net
Permalink | Reply | 0 comments |
headers
Bill Fenner | 11 May 04:41
Picon

Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt


On 5/10/05, Bruce Lilly <blilly <at> erols.com> wrote:
> 
> On Tue May 10 2005 04:50, Frank Ellermann wrote:
> >
> > Bruce Lilly wrote:
> >
> > >> Scott H. wants us to use the new 2234bis in the References.
> >
> > > A normative reference would hold up publication, as the 2234
> > > successor isn't yet a published RFC.
> >
> > <http://mid.gmane.org/046F43A8D79C794FA4733814869CDF0749C9AF <at> dul1wnexmb01.vcorp.ad.vrsn.com>
> >
> > It's not that I necessarily agree, but it's also not an issue
> > where I'd risk a debate with an AD if I care about the draft.
> 
> "Pay the AD now or pay the RFC Editor later".  The RFC Editor will
> hold up publication as an RFC until all normative references are
> published.

Seems unlikely that any newly-approved document is going to leapfrog
the already-approved 2223bis in the RFC Editor's queue, and then get
blocked by it.

http://www.rfc-editor.org/queue.html#crocker-abnf-rfc2234bis

It's true that in the reference, it's not obivous that it's as stable
and has as much of the IETF-approved imprimateur as the RFC does; this
is at least partly a symptom of the RFC publication process taking so
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frank Ellermann | 11 May 14:45
Picon
Picon

Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt


Bruce Lilly wrote:

> The RFC Editor will hold up publication as an RFC until
> all normative references are published.

As long as his queue is really a queue it should work.  They
have already identified the queue delay as major issue on the
general list, let's see how they fix it.  For "they" read
e.g. the articles by Margaret, and if Bill and Scott team up
to discuss this with the RfC editor I can only hope that his
last will is up to date.  The "new errata" procedure is also
not yet convincing.

> there are some serious problems with the ABNF draft
> (admittedly also in 2234):
> http://www1.ietf.org/mail-archive/web/ietf/current/msg34855.html

I've seen your discussions with Dave and Scott on the rfc-
interests list, and thought that all problems are resolved.

I don't see a "serious" problem in your article, some typos,
a nice to have non-essential idea how to improve comments -
which might be not backwards compatible, and who cares about
the semantics of standalone comments - and something about
CrLf on the IETF ftp-server, as far as I'm concerned that's
an issue of the ftp-server, not in 2234bis.

Any hint in the direction of [CR] LF instead of CRLF is IMHO
_dangerous_ - and I'm not talking about some angry MAC users
(Continue reading)

Permalink | Reply | 17 comments |
headers
Keith Moore | 11 May 17:26
Picon

Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt


Personally I don't see why a protocol specification shouldn't reference an old 
version of the ABNF spec, so long as we believe that the old ABNF specification 
is unambiguous enough to facilitate interoperability of the protocol specification.
There shouldn't be an imposed requirement to use the "latest and greatest"
notation just for the sake of fashion.

For some situations RFC 822's ABNF is superior to any of those which succeed it.

Keith
Permalink | Reply | 0 comments |
headers
ned+ietf-822 | 11 May 18:24

Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt


> On Tue May 10 2005 04:50, Frank Ellermann wrote:
> >
> > Bruce Lilly wrote:
> >
> > >> Scott H. wants us to use the new 2234bis in the References.
> >
> > > A normative reference would hold up publication, as the 2234
> > > successor isn't yet a published RFC.
> >
> > <http://mid.gmane.org/046F43A8D79C794FA4733814869CDF0749C9AF <at> dul1wnexmb01.vcorp.ad.vrsn.com>
> >
> > It's not that I necessarily agree, but it's also not an issue
> > where I'd risk a debate with an AD if I care about the draft.

> "Pay the AD now or pay the RFC Editor later".  The RFC Editor will
> hold up publication as an RFC until all normative references are
> published.  Expect a change in policy or delays in publication of
> documents with ABNF.  Note that there are some serious problems
> with the ABNF draft (admittedly also in 2234):
> http://www1.ietf.org/mail-archive/web/ietf/current/msg34855.html

I have to say I found none of the problems you described were "serious" in the
sense I understand the term. You found a bunch of typos, all of which can be
fixed during the author 48 hour period, and you had a concern about being able
to determine from the grammar what rule a comment is attached to, which I find
uninteresting since I reject the notion that comment binding needs to be
determinable from the grammar.

Oh, and then there was the business about line terminators used in stored
(Continue reading)

Permalink | Reply | 10 comments |

Gmane