Guidelines for Optional Services for Internet Fax Gateways
RFC 4161
Note: This ballot was opened for revision 08 and is now closed.
(Scott Hollenbeck) Yes
(Harald Alvestrand) (was Discuss) No Objection
Comment (2005-02-03)
No email
send info
send info
Reviewed by Spencer Dawkins, Gen-ART His comment on version -08: This revision seems to address just about every one of my (many) comments.
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Russ Housley) (was Discuss) No Objection
Comment (2004-08-17)
No email
send info
send info
This document could greatly benefit from a technical editor. Several parts are quite difficult to understand. Please remove the reference from the Abstract and replace it with "RFC 2305." Section 2.2 is missing a title. Please delete the 'Revision history' before publishing as an RFC.
(David Kessens) No Objection
(Allison Mankin) No Objection
Comment (2004-08-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
send info
This document has is pretty discursive. It covers features, none of them surprising or particularly hard to pull together. One bit of technology was promised in the intro and not actually specified, DTMF authorization. HDD and FDD are used but not expanded. There is an old-style IPR statement that indicates a claim was posted, but I can't see a claim on the page. In RFC 3667 times, we wouldn't be able to read a draft and know there was a disclosure for it anyway, so I wouldn't be able to ask about this, but in any event, I do wonder where the claim is (not to mention what in here could be claim-worthy, though that's moot).
(Bert Wijnen) No Objection
Comment (2004-08-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
send info
- citation in abstract - non-standard IPR statement - no IANA considerations section - RFC2119 not referenced, while such language is used - etc Similar comments have been made by others and there are 2 discusses which cover my comments.
(Ted Hardie) Abstain
Comment (2004-08-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
send info
A pass by a native speaker would help. There are several places where I found the document pretty hard to parse; here's an example from 2.1: For example, an MTA (Mail Transfer Agent) is set so that it puts mail with a different destination address in one mailbox. When the MTA receives broadcast mail (mail of more than one destination address), some kinds of MTAs copy the mail in one mailbox. Then, the offramp gateway uses POP to receive the mail from the MTA. As a result, the offramp gateway receives duplicate mail from the MTA. I think the paragraph before this and the overall topic (dropping duplicates) is clear enough that this isn't a DISCUSS, but the language there is a barrier rather than an enabler to communication. Dropping the whole paragraph might make this section more readable, but the problem is more general. Are the date and time format in 2.6 standardized somewhere? If so, a reference would be useful. I'm assuming that they are not, and that the local system must indicate what the format is. I also found it odd that the syslog protocol was not mentioned as an "existing network communication means" for this. None of the ones which are mentioned are in the references as either normative or informative. Why is section 3.1 present? It seems to say "nonstandard user authentication systems may exist".