headers
Frank Ellermann | 1 May 02:04
Picon
Picon

Re: Compatibility wit Netnews


Arnt Gulbrandsen wrote:

>> I'd rather stick with the liberal syntax for now, and maybe add a note
>> that says, "You SHOULD be conservative in what you generate, as
>> NO-WS-CTLs, quoted-pairs, and specials are known to cause heartburn
>> in some environments (cf. USEFOR)."

> +1. Proposed text: «It is RECOMMENDED to use only A-Z, a-z, 0-9, ".",
> "." and "/" on the left-hand side, and to make the left-hand side at
> most 64 characters long. Unusual but permitted syntax such as (for
> example) quoted-pairs are known to cause problems in some contexts.»

-1  

Where's the evidence that NO-WS-CTL is implemented AND interoperable ?
It's IMO harmful and a showstopper for DS.  It can't pass any gateway
to NetNews if used in Message-IDs.

Frank
Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 May 02:19
Picon
Favicon
Gravatar

Re: Compatibility wit Netnews


Pete Resnick <presnick <at> qualcomm.com> writes:

> I had a look at the USEFOR doc, and given how complicated msg-id syntax
> still is, I can't say I'm terribly inclined to start adopting it. If
> USEFOR had come to consensus to completely remove the no-fold-quote
> construct, I'd be a little more inclined.

Er, the only reason why we didn't do that is for RFC 2822 compatibility.
I sense a deadlock.  :)

NNTP would certainly love to eliminate as many quoting concepts as
possible out of message IDs, and in general any construct that permits the
same message ID to be represented by multiple different octet strings.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 1 May 02:13
Picon
Picon

Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt)


Arnt Gulbrandsen wrote:

>> If we want normative language like the above, we should really
>> just remove no-fold-quote (since quoted-string is already allowed
>> in the obs- syntax).

> Makes sense to me. Particularly since you can look for a long time
> before you find no-fold-quote in real message-ids. Standards are
> supposed to drop unused features as they advance, right?

Killing <no-fold-quote> is a nice idea, it simplifies the syntax
significantly.

And what about NO-WS-CTL in <no-fold-literal> ?  We can't also kill
<no-fold-literal>, how about limiting it to the literal syntax also
permitted in STD 66 ?  (Of course always in square brackets)

Frank
Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 May 02:22
Picon
Favicon
Gravatar

Re: I-D ACTION:draft-resnick-2822upd-01.txt


Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

> For the <msg-id> I'd like to see a syntax also working in NetNews, in
> news URIs, and in Archived-At links when they use a Message-ID.

For completeness, here's what RFC 3977 says about message IDs as used in
the NNTP protocol:

A.2.  Message-IDs

   Every article handled by an NNTP server MUST have a unique
   message-id.  For the purposes of this specification, a message-id is
   an arbitrary opaque string that merely needs to meet certain
   syntactic requirements and is just a way to refer to the article.

   Because there is a significant risk that old articles will be
   reinjected into the global Usenet system, RFC 1036 [RFC1036] requires
   that message-ids are globally unique for all time.

   This specification states that message-ids are the same if and only
   if they consist of the same sequence of octets.  Other specifications
   may define two different sequences as being equal because they are
   putting an interpretation on particular characters.  RFC 2822
   [RFC2822] has a concept of "quoted" and "escaped" characters.  It
   therefore considers the three message-ids:

      <ab.cd <at> example.com>
      <"ab.cd"@example.com>
      <"ab.\cd"@example.com>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ellermann | 1 May 02:24
Picon
Picon

Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt)


Pete Resnick wrote:

> I had a look at the USEFOR doc, and given how complicated msg-id
> syntax still is, I can't say I'm terribly inclined to start adopting
> it. If USEFOR had come to consensus to completely remove the
> no-fold-quote construct, I'd be a little more inclined.

USEFOR was forced to determine a maximal subset of 2822-Message-IDs
still working for its purposes, so that's a hen and egg issue.  If
2882upd removes <no-fold-quote> (still covered by "obs" of course)
then USEFOR can also get rid of it, I like the idea.  Syntactically
<no-fold-quote> is also a pain for I-D.ellermann-news-nntp-uri-05

> things like the "dot-doubling" worry me

It's only a consequence of how <dot-atom-text> is specified in 2822. 
Leading, trailing, or adjacent dots aren't allowed in dot-atom-text,
if folks want them anyway they have to use <no-fold-quote>.

Frank
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 1 May 03:46
Picon
Picon

Re: [2822upd] Resent-* MUSTard


ned+ietf-822 <at> mrochek.com wrote:

> It is in no way incumbent on this effort to change 2822bis to be
> compatible with either of these experiments, especially since the
> two experiments are incompatible with each other!

One of these experiments is strictly limited to SMTP, we can ignore
it here.  I think it's a bit unfair to say that the other experiment
is incompatible with 2822, when 2822 gives no reason why there's an
offending MUST NOT about Resent-* in automatic processing.

I'm too lazy to dig through MARID jabber logs now, but IIRC the PRA
concept was discussed in presence of the 822 and 2822 editors among
others.  It makes me wonder how important this MUST NOT is, and how
it's justified, I think there's nothing similar in 822.

>> In fact I think 2822upd should fix this issue.
> Then you need to make a very compelling argument for the change

For the MUST NOT I'd like to know a compelling reason why it's there,
otherwise 2119 might suffice to remove unnecessary MUSTard.

> some evaporate leaving only a very bad smell behind.

In the case of the PRA I'm curious if a part of its bad smell was
caused by an unnecessary / unclear / dubious / ... MUST NOT in 2822.

> It might arguably make sense to alter tnings based on the *outcome*
> of an experiment, but probably not as part of what's supposed to be
(Continue reading)

Permalink | Reply | 17 comments |
headers
Pete Resnick | 1 May 05:23
Favicon

Re: [2822upd] Resent-* MUSTard


On 5/1/07 at 3:46 AM +0200, Frank Ellermann wrote:

>2822 gives no reason why there's an offending MUST NOT about 
>Resent-* in automatic processing.

2822 does not say that Resent-* "MUST NOT be used in automatic 
processing". Don't partially quote. Read it again, in context.

As for why: It is because there was confusion about what MUAs ought 
to do with those fields, and using them for the reply command, and 
"*OTHER SUCH* actions" (was enough emphasis added?) would do the 
wrong thing.

>I use MIME when I forward mails or news, not Resent-*

Resent-* are *never* used when you "forward". That is also said in 
quite clearly in 3.6.6 (in the Note).

>but even if I'd use Resent-* I don't see why there could be multiple "authors"

So you've backed off of your original argument about the need for 
Resent-Sender (because it is needed when Resent-From is not identical 
to the sender) and you're just complaining about Ned's example?

I think it's more important for interoperability of implementations 
to keep the syntax of Resent-From and From identical (and the way 
it's always been) than to go verify that nobody is using this 
particular feature.
(Continue reading)

Permalink | Reply | 15 comments |
headers
Frank Ellermann | 1 May 07:01
Picon
Picon

Re: [2822upd] Resent-* MUSTard


Pete Resnick wrote:

>> 2822 gives no reason why there's an offending MUST NOT about
>> Resent-* in automatic processing.

> 2822 does not say that Resent-* "MUST NOT be used in automatic
> processing". Don't partially quote. Read it again, in context.

I've read it several times because William quoted it in his appeal
<http://www.ietf.org/IESG/APPEALS/appeal2-draft-lyon-senderid.txt>

He quoted the "note" adding two references to statements by you.

And he quoted the immediately preceding MUST NOT about Resent-*
in automatic processing as separate argument.  If you think that
this "MUST NOT" doesn't affect whatever SenderID does, then the
context needs to be clearer.

> As for why: It is because there was confusion about what MUAs ought
> to do with those fields, and using them for the reply command, and
> "*OTHER SUCH* actions" (was enough emphasis added?) would do the
> wrong thing.

How about rewording this statement:

- strictly informational.  They MUST NOT be used in the normal
- processing of replies or other such automatic actions on messages.
+ mainly informational.  They MUST NOT be used in the normal
+ processing of replies or the creation of auto-responses [RFC 3834].
(Continue reading)

Permalink | Reply | 14 comments |
headers
Philip Guenther | 1 May 09:05
Favicon

Re: [2822upd] Resent-* MUSTard


On Tue, 1 May 2007, Frank Ellermann wrote:
> Pete Resnick wrote:
...
>>> I use MIME when I forward mails or news, not Resent-*
>
>> Resent-* are *never* used when you "forward". That is also said in
>> quite clearly in 3.6.6 (in the Note).
>
> Sure, but the desired effect is often the same, I got a mail and want
> you to read it.  I can MIME-forward or resend it to you.  With MIME I
> can add a reason why I think that it might interest you, with MIME I
> can also forward more than mail.  But if I don't pick any additional
> option offered by MIME the effect is almost the same, you get the
> original mail incl. original header and original body.

I'm not sure I would even call the effects of resending vs encapsulating 
_similar_, much less "almost the same".  The very fact that they behave 
differently is a Good Thing, as it means they can express differences in 
intent.  When I want to add someone to a conversational thread, I resend 
to them the latest message (occasionally more than one) so that their 
replies naturally go back to the current set of recipients.  When I want 
to inform someone of something or start a side conversation, I forward it 
to convey that replies probably should go back to me.  They can reply 
however they want, of course, but it conveys my intent and helps avoid 
misaddressing.

Heck, the difference between resending and forwarding is *much* greater 
than the difference between To and Cc recipients.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arnt Gulbrandsen | 1 May 09:05
Favicon

Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt)


Dave Crocker writes:
> In effect, the issue here is defining a sub-set profile that permits 
> gatewaying between Internet mail and Netnews.  A thoroughly laudable 
> goal, but not one for RFC2822bis...

Mumble.

Netnews may be an important reason why no-fold-quote and its kid aren't 
used in message-ids. But the reason doesn't matter for 2821bis: 
Standards-track documents are supposed to drop unused features as they 
progress, no matter why these features are unused.

Arnt
Permalink | Reply | 0 comments |

Gmane