Re: 2119bis
On Tue, 30 Aug 2011, Martin Sustrik wrote: For an implementor it's often pretty hard to decide whether to implement functionality marked as SHOULD given that he has zero context and no idea whether the reason he has for not implementing the feature is at all in line with RFC authors' intentions. It's really simple. If an interoperability problem arises from your failure to implement a SHOULD, then it's your fault. --apb (Alan Barrett) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
On Mon, 28 Dec 2009, John Levine wrote: But I see little wisdom in adding another does-not-exist name with semantics not meaningfully different from .INVALID or FOO.INVALID. I think the semantics are meaningfully different, in that applications are allowed to know that .invalid is special, but should not know that sink.arpa (or nonexistent.arpa) is special. --apb (Alan Barrett) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
On Mon, 21 Dec 2009, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Eternal Non-Existence of SINK.ARPA (and other stories) ' draft-jabley-sink-arpa-02.txt as a BCP I would like to see a requirement (or at least a recommendation) that DNS or application software must/should not have any special knowledge of the fact that SINK.ARPA does not exist; they should discover its nonexistence when and if they try to follow a reference to the name, in the same way that they discover the nonexistence of any other domain names. In the examples, I would like to see reinforcement of the above principle. For example, the should in Installing an MX record ... should cause compliant MTAs to ... is a prediction about the behaviour of compliant MTAs when encountering *any* nonexistent domain name; it is not a requirement for special treatment of the SINK.ARPA name, but some people might interpret the exmple as a requirement for special treatment. I don't like the name SINK much; calling something a sink implies that traffic can be sent to it, and that such traffic will be read and discarded, but that's not what's going on here. I prefer NONEXISTENT.ARPA or some variation on that theme. --apb (Alan Barrett) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'BinaryTime: An alternate format for representing date and time in ASN.1' to Experimental RFC
On Mon, 15 Nov 2004, Graham Klyne wrote: Has there been detailed discussion of leap second issues? What exactly does the revised text ignoring leap seconds actually mean (I think I can guess, but I also think there's some room for misinterpretation here)? I assume it means assuming exactly 86400 seconds per day. --apb (Alan Barrett) ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Principles of Spam-abatement
On Fri, 12 Mar 2004, Nathaniel Borenstein wrote: I'm not talking about any party to the real end-to-end email transaction. I'm talking about intermediaries. I have no problem at all with user-controlled filters that do whatever they want. It's when an ISP starts doing these things on behalf of a user who doesn't understand or want them that the problems arise. Your remedy should be truth-in-advertising enforcement, as Vernon said. Entities that filter in the way that you don't like are not providing real Internet access, and should not pretend to. --apb (Alan Barrett)
Re: Principles of Spam-abatement
On Wed, 03 Mar 2004, Dave Crocker wrote: What makes this such an interesting problem is the critical need for spontaneous (unsolicited and uncoordinated) communication is many human activities. Eliminating the ability to have new people show up without an appointment will cripple some activities. It ought to be possible to consent to contact without an appointment. For example, you could have a protocol that allows you to encode rules like I consent to receiving messages from new people, provided that the messages purport to be related to certain specified topics, and provided that one of a set of specified escrow agents vouches for the existence of a bond of a specified value to be paid if the message is not what it purports to be. --apb (Alan Barrett)
Re: wcard-clarify breaking RFC 2308 NXDOMAIN
On Thu, 28 Aug 2003, D. J. Bernstein wrote: Let me get this straight. After the BIND company (1) issues an RFC that clearly allows NXDOMAIN in this situation, (2) tells a new implementor that NXDOMAIN in this situation is fine, (3) publishes BIND 9, which uses NXDOMAIN in this situation, and (4) allows this use of NXDOMAIN to be deployed for four years, (1) did not happen. (2) was a mistake by one person, not by a company or the IETF. (3) is a bug in bind 9. (4) is a bug in bind 9. you think it's perfectly reasonable for the BIND company to change its mind and publish a new RFC saying---without a shred of justification--- that NXDOMAIN in this situation is prohibited? Since the premises to not hold, the conclusion makes no sense. --apb (Alan Barrett)
Re: IETF jabber howto pointers please?
On Mon, 14 Jul 2003, Peter Saint-Andre wrote: Could somebody re-post a pointer to the canonical 'IETF jabber' howto please? http://www.jabber.org/ietf/chat.php Two questions: 1) Are there any open-source text-based clients that actually work? I prefer not to have to use a graphical environment to view text, and I couldn't get sjabber to work. 2) Jabber, Inc. (jabber.com) are spammers, and I would not want to support them in any way. It appears that Jabber is a trademark owned by the spammers, and this bothers me. Does jabber.org have a position on spam? --apb (Alan Barrett)
Last Call: MIME Security with OpenPGP to Proposed Standard
On Fri, 27 Apr 2001, The IESG wrote: The IESG has received a request from the An Open Specification for Pretty Good Privacy Working Group to consider MIME Security with OpenPGP draft-ietf-openpgp-mime-06.txt as a Proposed Standard. draft-ietf-openpgp-mime-06.txt assumes that the content-transfer-encoding of a body part in a multipart MIME message will remain unchanged end to end. That assumption is not valid. Some currently deployed mailers (including sendmail) will convert body parts to or from 8bit content-transfer-encoding. It's quite possible that a body part could originate in quoted-printable, be signed like that, and be converted to 8bit before delivery. In 1998, many messages to the IETF list ended up with headers like this, showing conversion to 8bit during delivery of the incoming message to the list exploder, and conversion from 8bit during delivery of the outgoing messages to the subscribers: X-MIME-Autoconverted: from Quoted-printable to 8bit by ietf.org id LAA20175 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAB20435 Similar behaviour is visible today in other mailing lists, but apparently not the ietf list. I believe that it's a mistake for OpenPGP to sign the transfer-encoded form of any message. The signature should be over the canonical form of the message, and signature verification should be insensitive to changes in content-transfer-encoding. --apb (Alan Barrett)
