Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and Protocols) to Proposed Standard

[SM <[e-mail]>]

At 19:44 21-09-2008, Russ Allbery wrote:
>(I am not a subscriber to the ietf list and would appreciate copies of
>replies.)

Cc as requested.

>The message is still meaningful; however, it violates a SHOULD in RFC 2822
>(well, sort of, depending on how you interpret "belong" in the case of an
>address that by definition doesn't belong to anyone).

The message may be meaningful for a broadcast but not for two-way 
communication.  For example, if you were reading this mailing list 
and replying to this message through Netnews, I would not be able to 
send you a reply.

As obfuscated mailboxes such as example@example dot nospam dot com 
are commonly used in Netnews, proposing ".invalid" as a suffix at 
least ensures that the mailboxes is actually invalid.

>I think a gateway has two acceptable choices: preserve the From header and
>violate the SHOULD, or replace the From header with some contact address
>for the gateway (a copy of the Sender header, for example).  From a
>quality of implementation perspective, as a consumer of a gateway, I'd
>much prefer the former behavior.

In this case, it may be better to violate the "SHOULD" and provide an 
valid mailbox to which replies can be sent (second choice).

>Regardless, however, news-to-mail gateways are not standardized by this
>draft, so I don't think this is an issue for this document.  See 3.10.1:
>
>    From the perspective of Netnews, an outgoing gateway is just a
>    special type of reading agent.  The exact nature of what the outgoing
>    gateway will need to do to articles depends on the medium to which
>    the articles are being gated.
>
>I think work on a best-practices guide for gateways would be great, but I
>think the e-mail side of the gateway is outside the scope of this
>document.

Section 3.10.1 mentions practices that are encouraged.  As the 
document "creates" the problem, it may be good for the document to 
address it especially given the different interpretations of 
"meaningful".  I suggest the following in Section 3.10.1:

    5.  The message should be compliant with the specifications for 
that medium.

>This wouldn't be a gateway; it would be transmission of a news article
>through e-mail.  See 3.10:

I suggested that as an alternative to work around the issue if you 
prefer not to fix the invalid address.

>Yes, thank you.  I now have:
>
>    2.  The proto-article is sent as an email with the addition of any
>        header fields required for an email as defined in [RFC2822], and
>        possibly with the addition of other header fields conventional in
>        email such as To and Received.  The existing Message-ID header
>        field SHOULD be retained.

I don't see the need for specifying additional headers.  You could 
keep it simple with the following:

    2.  The proto-article is sent as an email with the addition of any
        header fields required for an email as defined in [RFC2822].
        The existing Message-ID header field SHOULD be retained.

>Hm.  Well, if we were to add a new header field, it really needs to go
>into USEFOR and not here, since USEFOR is the canonical document for
>header fields for netnews articles.  USEFOR has already gone through Last
>Call, however.
>
>I can see your point here, but I'm not sure the lack is particularly
>important.  I'd really rather not see us make further changes to USEFOR;
>generally an X-* header is used for this and is adequate in practice.

Each implementation might use a different header field name.  It's 
might become a problem in future.

>Well, this is very explicitly an example based on a specific
>implementation, which happens to use an X-* header.  But I can see where
>this would be less than ideal.  However, as above, I'm hesitant to invent
>a new header for this purpose and add the necessary machinery for
>registering it when there is no standardized existing practice and it's
>not clear what issues are involved in picking a header field,
>standardizing its format, and so forth.

Implementors will likely pick X-Gateway as you mentioned that header 
name in the example.  Once people start using specific headers, it's 
difficult to depreciate them in favor of some standardized format.

Regards,
-sm