headers
Pete Resnick | 2 Feb 21:41
Favicon

2822upd-06 submitted


I couldn't get the upload tool working, so I mailed it in. You can 
see it at my website as usual:

<http://resnick1.qualcomm.com/draft-resnick-2822upd-06.txt>
<http://resnick1.qualcomm.com/draft-resnick-2822upd-06.html>
<http://resnick1.qualcomm.com/draft-resnick-2822upd-06.xml>

And the diff from -05 here:

http://tools.ietf.org/rfcdiff?url1=http://resnick1.qualcomm.com/draft-resnick-2822upd-05.txt&url2=http://resnick1.qualcomm.com/draft-resnick-2822upd-06.txt

Basically, re-fixed all of the -list constructs (no more obs-commas) 
and made a couple of editorial fixes.

pr
--

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Permalink | Reply | 5 comments |
headers
Frank Ellermann | 4 Feb 03:08
Picon
Picon

2822upd-06 Sender


Hi, on the DKIM list a poster claimed that Sender is OPTIONAL.
Looking for the evidence why that's wrong in 2822upd I found
an unclear SHOULD:

1:  from multiple authors    => MUST (table 3.6 and in 3.6.2)
2:  one author = transmitter => SHOULD NOT (redundant, 3.6.2)
3:  otherwise SHOULD (3.6.2)

I don't get case (3), why is it only a SHOULD ?  For anything
that's not covered by (2: one author = transmitter) I'd expect
a MUST:

- Otherwise, both fields SHOULD appear.
+ Otherwise, both fields MUST appear.

What could be a plausible excuse to ignore the SHOULD in (3) ?

 Frank
Permalink | Reply | 3 comments |
headers
Hector Santos | 4 Feb 04:10
Favicon

Re: 2822upd-06 Sender


Frank Ellermann wrote:
> Hi, on the DKIM list a poster claimed that Sender is OPTIONAL.
> Looking for the evidence why that's wrong in 2822upd I found
> an unclear SHOULD:
> 
> 1:  from multiple authors    => MUST (table 3.6 and in 3.6.2)
> 2:  one author = transmitter => SHOULD NOT (redundant, 3.6.2)
> 3:  otherwise SHOULD (3.6.2)
> 
> I don't get case (3), why is it only a SHOULD ?  For anything
> that's not covered by (2: one author = transmitter) I'd expect
> a MUST:
> 
> - Otherwise, both fields SHOULD appear.
> + Otherwise, both fields MUST appear.
> 
> What could be a plausible excuse to ignore the SHOULD in (3) ?

Nothing wrong with the statement in 2822 section 3.6.2:

    If the originator of the message can be indicated
    by a single mailbox and the author and transmitter are identical, the
    "Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
    appear.

-1 only trying to change something that isn't broken and on enforcing 
something that will immediately make existing systems non-compliant for 
no reality plausible reason.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pete Resnick | 4 Feb 04:39
Favicon

Re: 2822upd-06 Sender


On 2/4/08 at 3:08 AM +0100, Frank Ellermann wrote:

>Hi, on the DKIM list a poster claimed that Sender is OPTIONAL.

Of course, that's obviously false. Sender is not OPTIONAL (defined in 
section 5 of RFC 2119). There are cases where it is REQUIRED (section 
1 of 2119) and cases where "there may exist valid reasons in 
particular circumstances to" not have a Sender, "but the full 
implications must be understood and carefully weighed before choosing 
a different course" (section 3 of 2119). As you say:

>1:  from multiple authors    => MUST (table 3.6 and in 3.6.2)
>2:  one author = transmitter => SHOULD NOT (redundant, 3.6.2)
>3:  otherwise SHOULD (3.6.2)
>
>I don't get case (3), why is it only a SHOULD ?  For anything that's 
>not covered by (2: one author = transmitter) I'd expect a MUST:
>
>- Otherwise, both fields SHOULD appear.
>+ Otherwise, both fields MUST appear.
>
>What could be a plausible excuse to ignore the SHOULD in (3) ?

Two that I can come up with off the top of my head:

- The agent responsible for the actual transmission of the message is 
the company lawyer who vets every e-mail message before sending it 
out. But the lawyer's identity should not be revealed to the rest of 
the world for security reasons.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frank Ellermann | 4 Feb 06:24
Picon
Picon

Re: 2822upd-06 Sender


Pete Resnick wrote:

> There are cases where it is REQUIRED (section 1 of 2119) and
> cases where "there may exist valid reasons in particular 
> circumstances to" not have a Sender, "but the full implications
> must be understood and carefully weighed before choosing 
> a different course" (section 3 of 2119).

Right, and that can be difficult if the sender has no idea
about auth* schemes building on accurate info (SenderID and
maybe some future DKIM SSP scenarios).

> - The agent responsible for the actual transmission of the
>   message is the company lawyer who vets every e-mail
>   message before sending it out. But the lawyer's identity
>   should not be revealed to the rest of the world for
>   security reasons.

They could use a role account for this task.  Or pretend that
the author submitted the mail when the real Sender would be
in the same domain (i.e. most likely irrelevant).

> - The agent responsible for transmission is *really* hard to 
>   determine. A particular system may have an audit log which
>   can figure out who sent it later, but that information is
>   unavailable when the message itself is being sent.

RFC 4409 8.1 is clearly an OPTION, and as long as it is about
the same domain I don't care about SHOULD vs. MUST.  But for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ellermann | 4 Feb 07:38
Picon
Picon

Re: 2822upd-06 submitted


Pete Resnick wrote:

> And the diff from -05

Thanks.  Stuff I stumbled over while looking at the diff:

---- 1: <obs-domain-list>

RFC 821 uses the syntax:

| <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
| <at-domain> ::= "@" <domain>

RFC 2821 and 2821bis agree with that idea:  There are no
"null" <at-domain>s.  Why do 2822 and 2822upd keep the
RFC 822 ASCII-art commas in source routes, when that was
never allowed in (2)821(bis) ?

---- 2: Routes SHOULD be ignored

| When interpreting addresses, the route portion SHOULD
| be ignored. 

That statement in isolation *after* the syntax is odd,
why not add it to the prose before the ABNF ?  Proposal:

= There are four primary differences in addressing.  First,
= mailbox addresses were allowed to have a route portion
= before the addr-spec when enclosed in "<" and ">".  The
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pete Resnick | 4 Feb 20:17
Favicon

Re: 2822upd-06 submitted


On 2/4/08 at 7:38 AM +0100, Frank Ellermann wrote:

>RFC 821 uses the syntax:
>
>| <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
>| <at-domain> ::= "@" <domain>

Which flatly disagreed with 822 on this point:

      route       =  1#("@" domain) ":"           ; path-relative

      2.7.  #RULE:  LISTS

           A construct "#" is defined, similar to "*", as follows:

                               <l>#<m>element

      indicating at least <l> and at most <m> elements, each  separated
      by  one  or more commas (","). This makes the usual form of lists
      very easy; a rule such as '(element *("," element))' can be shown
      as  "1#element".   Wherever this construct is used, null elements
      are allowed, but do not  contribute  to  the  count  of  elements
      present.   That  is,  "(element),,(element)"  is  permitted,  but
      counts as only two elements.  Therefore, where at least one  ele-
      ment  is required, at least one non-null element must be present.
      Default values are 0 and infinity so that "#(element)" allows any
      number,  including  zero;  "1#element" requires at least one; and
      "1#2element" allows one or two.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Crocker | 4 Feb 21:14

[Fwd: STD 68, RFC 5234 on Augmented BNF for Syntax Specifications: ABNF]


FYI.

(Sorry for the cross-posting, but I can't think of a single-best list to post to.)

-------- Original Message --------
Subject: STD 68, RFC 5234 on Augmented BNF for Syntax Specifications: ABNF
Date: Thu, 31 Jan 2008 17:24:14 -0800 (PST)
From: rfc-editor <at> rfc-editor.org
To: ietf-announce <at> ietf.org, rfc-dist <at> rfc-editor.org
CC: rfc-editor <at> rfc-editor.org

A new Request for Comments is now available in online RFC libraries.

         STD 68
         RFC 5234

         Title:      Augmented BNF for Syntax Specifications:
                     ABNF
         Author:     D. Crocker, Ed.,
                     P. Overell
         Status:     Standards Track
         Date:       January 2008
         Mailbox:    dcrocker <at> bbiw.net,
                     paul.overell <at> thus.net
         Pages:      16
         Characters: 26359
         Obsoletes:  RFC4234
         See Also:   STD0068
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ellermann | 5 Feb 19:09
Picon
Picon

Re: 2822upd-06 submitted


Pete Resnick wrote:

[quotes rearranged]

>>---- Last Call now ?

> Tony? I'm all for it.

Catch that runaway 2821bis, and maybe even Usefor.

Both are not directly affected by the fine prine
print of <obs-NO-WS-CTL> in <obs-dtext>.  They
have their own ways of saying "no obs" or "no CTL".

 [routes] 
> Which flatly disagreed with 822 on this point:

Yes, and my point was that this was always wrong
in the RFC 822 syntax.  If you think that serial
commas work as expected in a route it is fine, but
"something" has to trim them for SMTP.

And we are talking about "something" that ignores
several SHOULD NOT in 2821bis and 2822upd.  I have
no idea what happens if serial commas end up in
SMTP paths, stricty speaking this is a syntax error.

> it was always the case that things which generated
> 821 commands from 822 headers had to do all sorts
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 11 Feb 17:49
Picon
Picon

Re: 2822upd-06 submitted


In <p06250120c3ca8525e3ea@[74.134.5.163]> Pete Resnick <presnick <at> qualcomm.com> writes:

>I couldn't get the upload tool working, so I mailed it in. You can 
>see it at my website as usual:

OK, I have compared it with -04, and it is mostly fine. In particular the
<quoted-pair> is now gone from the places where it could have caused any
trouble. So I think the only renmaining differences between msg-id here
and in USEFOR (assuming USEFOR can now get rid of its own attempts to fix
the problems) is that 2822bis still allows '>' in a no-fold-literal and
USEFOR does not. But we can probably live with that. Perhaps Frank could
confirm that there are no other msg-id interoperability issues left.

A couple of niggles:

In 2.2.3:

"An unfolded header field has no length restriction and therefore may be
infinitely long."

I doubt that is possible :-( . I suggest s/infinitely/indefinately/.

And in Appendix B:

"9.   Removed quoted-pair from domain literals.*"

I think they are removed from no-fold-literals also. And where did that
'*' come from?
(Continue reading)

Permalink | Reply | 1 comment |

Gmane