> Bruce Lilly wrote:
> >
> > Review of draft-shafranovich-feedback-report-01 by B. Lilly
> >
> ...
> >
> > [X] The document should probably be split: registration of media
> > types in the standards tree requires an RFC of any type.
> > Registration procedures (which should be specified for
> > registration of extension items) are typically specified in a BCP
> > RFC. Specifications with conformance criteria (which should be
> > explicit) are typically Standards Track RFCs.
> >
> Can you elaborate as to why the document must be split? For example, RFC
> 3464 includes the MIME registration in the same document. Why should
> this document, which is also a child-of-RFC3462 be any different?
Registration != registration procedure. IMO it is perfectly reasonable to
include most sorts of registrations in practically any sort of document. There
certainly should not be any blanket prohibition saying, e.g., things cannot be
registered in an experimental specification.
Registration procedures may be another matter. These are administrative
practices, not protocol specifications. As such, they cannot be subjected to
the criteria for advancement along the standards track. (Indeed, the entire
idea of having a single consistent registry is somewhat at odds with the notion
of multiple independent implementations, isn't it?) Experiemental and
informational status are also clearly inappropriate, as neither have strict
enough criteria, and experience has shown that registration procedures need
careful review. BCP status, however, is a pretty good match, good enough that the
more important registration procedures in the IETF have been been published as
separate BCPs.
OTOH, having a separate document for a simple, rarely used registration
mechanism is overkill. So including such procedures in a standards-track
document is allowed, if not actually encouraged. See RFC 3464 for one such
example.
This document contains both registration procedures (for feedback types and
extension fields) as well as a media type registration. The latter clearly do
not require a separate document, the former are IMO simple enough that a
separate document isn't needed. I would suggest, however, that you check out
RFC 3464 and adopt the approach it uses for setting up the registries.
I also note that RFC 3462 is not an appropriate example since it only contains
registrations, not new registration procedures. (In fact it cleverly avoids
creating a separate registry for report types by piggybacking report types on
top of a MIME registration for the report format.)
> > The document suffers from the following serious defects:
> >
> ...
> >
> > [X] missing or inadequate internationalization considerations
> >
> I am not sure what this is refering to. This is a message intended for
> machines, not humans, and follows the same conventions as RFC 3462 from
> which it descends. What internationalization issues have to be discussed?
The draft specifically talks about the format having human readable parts.
OTOH, it is unclear to me what needs to be said about internationalizing such
text.
> > [X] incompatible with one or more Internet Standards
> >
> Can you be more specific? What Internet standards is this document not
> compatible with, what specific issues are there, etc.?
> >
> > Specific issues with the draft:
> >
> ...
> > o The draft implies that "opt-out" is viable. It is not, and the
> > draft will meet some considerable resistance if it does not
> > distance itself from that spammer-supported concept. (opt-out is
> > not viable because there are more than 10 billion potential senders
> > of unsolicited material (nearly that many individuals, plus a large
> > number of corporate entites). Responding to a single message from
> > each, at 5 seconds per response, working continuously, would take
> > more than 1,500 years of uninterrupted effort. How long do you
> > plan to live, and do you wish to do something other than "opt-out"
> > of unsolicited messages?)
> >
> This is a technical standard, not an editorial page. The "opt-out"
> option is included to be used in feedback loops from ISPs to legit bulk
> mailers such as SkyList, etc., not a general opt-out mechanism. It is
> perfectly viable according to the ISPs and the bulk mailers I have
> spoken to.
I concur.
> > o The draft states "this format is intended specifically for
> > communications among providers", implying that a mere individual
> > (not a provider) cannot use it to report abuse to a government
> > agency (also not a provider), for example.
> >
> I will change it to read "this format is intended primarly for
> communications among providers, but can also be used in other
> situations". Would that be more clear?
Seems like a reaonable change to me.
> > o The draft states "The first MIME part of the message contains a
> > human readable description of the report" but does not state
> > whether or not that part can be a MIME composite type (e.g.
> > multipart/alternative). Nor does it provide for (e.g.) an audio
> > type, which might be appropriate if the recipient is known to be
> > visually impaired.
> >
> This is a child-of-RFC3462. Whatever is specified there, applies here.
> Last time I checked, I did not see any of those options there or in any
> standards that descend from it such as DSNs and MSG-TRACK.
The use of multipart/alternative as the first part of a report was discussed at
length during the design of RFC 1892 (now RFC 3462). AFAIK no agreement was
ever reached to describe such usage. OTOH, no agrement was reach to ban such
usage either.
We've suported the use of multpart/alternative in the first part of both DSNs
and MDNs for quite a while now. AFAIK nobody ever uses the capability. Given
that this usage is far more targetted than the use of DSNs and MDNs is, I
cannot see this being a problem.
> > o The draft states "it is RECOMMENDED that the entire original email
> > message be included without any modification" but does not indicate
> > how such a message containing a virus or other malware can be
> > successfully conveyed in the presence of filtering (at the sender's
> > site, in transit, or at the intended recipient's site) without
> > encryption and/or encoding.
> This issue was brought up by someone already. One option would be to
> relay just the headers of the message (an option included in this
> document). However, the consensus in the discussions that I had with
> ISPs is that this is something out of scope for this document. Rather,
> this is an issue for the abuse desks (sender and receiver) to deal with.
You need to describe the issue at least, because people won't think about it
and will end up with the notifications getting caught in some filter somewhere.
(I only wish I wasn't speaking from experience here.)
> I do not see any other plausible solution short of mucking around with
> the RFC3462 format and making this even more complicated. Both ISPs and
> abuse desks have expressed their desire to keep this simple.
Agreed.
> > o The draft states "The subject line of the feedback report SHOULD be
> > the same as the included email message", which conflicts with the
> > defined semantics of the Subject field as stated in RFC 2822, viz.
> > a description of the topic of the message containing it, not a
> > purported description of a different message.
> This was included due to the fact that smaller ISPs tend to use the
> Subject line for manual processing. This is currently the accepted
> convention and I don't know if mandating anything else will actually
> accomplish something.
> However, what about prefixing the subject as follows:
> "[FEEDBACK REPORT:] subject"
> ?
Seems like a reasonable compromise to me. This is already done routinely
with DSNs and MDNs.
> > o The draft refers to RFC 2616, which is an HTTP specification that
> > uses a different field syntax from the Internet Message Format.
> I did not find any other standard that defines the user agent field. The
> "User-Agent" and "Mailer" fields used by email programs are not defined
> in any standard that I was able to locate. Perhaps a new registration or
> document for the user agent field should be written, OR the syntax
> copied from RFC 2616 and included in this document in long hand.
Probably best to copy it rather than reference HTTP.
> > o In several proposed fields, e.g. "Original-Mail-From:", the draft
> > makes statements such as "The format of this field is defined in
> > section 4.1.1.2 of RFC 2821", whereas there is no such definition
> > of any such fields in the referenced RFCs.
> It is refering to the following:
> "MAIL FROM:" ("<>" / Reverse-Path)
> [SP Mail-parameters] CRLF
> Specifically to everything that appears after MAIL FROM. The format is
> probably the same as Return-Path header, but I wanted to reference the
> original SMTP transaction directly.
Then you need to make it clear you are importing a definition from a different
sort of protocol field.
> > o The draft seeks to define a media type with multiple fields (but
> > N.B. not *header* fields in this case), but does not provide enough
> > detail:
> > o Where's the syntax specification for the format?
> > o What order should the fields appear in?
> > o Is the order significant?
> > o May empty lines appear between fields?
> This is a child-of-RFC3462.
Which doesn't define the format of the report part. You'd need to refer to RFC
3464 and its definition of message/delivery-status for this, assuming that you
actually want a report format with one block of stuff for the message and a
separate block for each recipient. (It isn't clear to me whether you want this
or not - the only field you defined that's per-recipient is original-rcpt-to.
Yet you say this field can only appear once...) Things can be simplified
considerably if there's only one block of information in the second part.
> > o What about the promised extensibility?
> >
> There is an extensibility section.
That may be the intent, but absent a specification of the report format it is
hard to know if the field list is open-ended or not.
> > o Where are the syntax specifications for the fields?
> >
> Are you refering to ABNF?
You currently define all the fields by text referecne to other specifications.
IMO it would be better to have ABNF for them all, importing ABNF productions
from other specifications as needed.
> > o Where are the BCP 90 registration templates for the fields?
> DNS and message tracking standards do not register their fields with BCP
> 90 IANA registry. Since this is a similar child-of-RFC3462, I do not see
> why it should be any different.
I think you meant DSN, not DNS. In any case, I agree that these are not
header fields and hence do not belong in the regular header field
registry.
> > o The media type registration form doesn't say anything about a
> > charset parameter, or about required charsets. Can I send such a
> > report in EBCDIC?
> >
> This is a child-of-RFC3462, everything that applies there applies here
> as well (only 7bit ASCII).
Again, RFC 3462 only defineds the report framework, not the report content.
You either need to specify this stuff or refer to RFC 3464.
> > o The draft provides a catch-all "other - any other feedback that
> > doesn't fit into other types". How does one distinguish a
> > subsequent extension from "other" (hint: only register types that
> > have a specific definition)?
> >
> Other specifically refers to a case where the abuse reporter DOES NOT
> want to specific a specific feedback type and leave that task for the
> receiver.
Having to infer the intent of the sender seems like a bad idea to me.
> > o There is provision for one specific type of malware -- "virus", but
> > not other types (worms, dialers, keystroke loggers, logic bombs,
> > etc.). The Security Glossary FYI may be a useful reference.
> >
> I assumed that it includes all malware.
> > o The Security considerations section is completely unacceptable.
> Obviously, this is only a draft at this point and has not been sent to
> the IESG or anyone else for approval just yet. Rather, it is still
> something that needs work, and specific suggestions would be highly
> welcome. Blanket statements like the one above are not much helpful - of
> course I am aware that this section is not finished yet. If you would
> like to help writing it, I would be very happy.
It is never too soon to start working on your security considerations...
> > o References are normally unnumbered sections.
> Can you provide a reasoning for this or is this simply something the
> community is used to?
It is what the RFC Editor requires. Adopting the format of the final RFC sooner
rather than later often saves time.
> > o Discussion venue should be an IETF list for documents intended as
> > IETF documents.
> There is no current IETF list for this type of stuff. The ietf-822 list
> is not official at this point. When this spec becomes more mature, I
> will discuss with the appropriate ADs the best avenue for moving this
> forward. But for now, there is already a dedicated list for this.
IMO discussing this on ietf-822 is fine. But that's just MO.
Ned
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.