BGPsec Operational Considerations

From nobody Thu Jun 11 01:19:31 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8DD1AC449 for ; Thu, 11 Jun 2015 01:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wntJfvsSdw1E for ; Thu, 11 Jun 2015 01:19:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC581AC442 for ; Thu, 11 Jun 2015 01:19:27 -0700 (PDT) Received: from localhost ([::1]:36176 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z2xhu-0006HA-Gc; Thu, 11 Jun 2015 01:19:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, magnus.westerlund@ericsson.com X-Trac-Project: xml2rfc Date: Thu, 11 Jun 2015 08:19:26 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/298 Message-ID: <078.7d986ba2b3bb43196354016a8cf91302@tools.ietf.org> X-Trac-Ticket-ID: 298 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, magnus.westerlund@ericsson.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: xml2rfc@ietf.org Subject: [xml2rfc] #298 (Version 2 cli): PDF output fails to show link for second of two XREFs X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 08:19:30 -0000 #298: PDF output fails to show link for second of two XREFs A reviewer of my one of my drafts noted that the PDF version generated for my document by the datatracker. I don't know what options this has as it looks like the PDF generated in text but with links. The same issue exists for xml2rfc.ietf.org generated web page as pdf output. The issue is that in section 8 of: https://tools.ietf.org/pdf/draft-ietf-rtcweb-rtp-usage-24.pdf I have two xrefs directly after each other and the produced output is: "A large number of additional performance metrics are supported by the RTCP Extended Reports (XR) framework [RFC3611][RFC6792]." The issue in the PDF is that the second one does not have a link, while the first one has. The xml source for this looks like this: A large number of additional performance metrics are supported by the RTCP Extended Reports (XR) framework, see . At the time of this writing, it is not clear what extended metrics are suitable for use in WebRTC, so there is no requirement that implementations generate RTCP XR packets. However, implementations that can use detailed performance monitoring data MAY generate RTCP XR packets as appropriate; the use of such packets SHOULD be signalled in advance. Yes, I have modified the text slightly, but it still generates this bug. -- --------------------------------------------+------------------------------ Reporter: magnus.westerlund@ericsson.com | Owner: Type: defect | henrik@levkowetz.com Priority: medium | Status: new Component: Version 2 cli | Milestone: Keywords: | Version: 2.4.x --------------------------------------------+------------------------------ Ticket URL: xml2rfc From nobody Thu Jun 11 02:08:12 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7941B2DDE for ; Thu, 11 Jun 2015 02:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C59xYhyTrSTo for ; Thu, 11 Jun 2015 02:08:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145651B2DDD for ; Thu, 11 Jun 2015 02:08:09 -0700 (PDT) Received: from localhost ([::1]:38313 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z2yT2-0006LY-1G; Thu, 11 Jun 2015 02:08:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: henrik@levkowetz.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Thu, 11 Jun 2015 09:08:08 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/298#comment:1 Message-ID: <093.4a95f44c1121a512cca5ab653a0eec36@tools.ietf.org> References: <078.7d986ba2b3bb43196354016a8cf91302@tools.ietf.org> X-Trac-Ticket-ID: 298 In-Reply-To: <078.7d986ba2b3bb43196354016a8cf91302@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] #298 (Version 2 cli): PDF output fails to show link for second of two XREFs X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 09:08:10 -0000 #298: PDF output fails to show link for second of two XREFs Changes (by julian.reschke@gmx.de): * status: new => closed * resolution: => invalid Comment: That's a bug in the rfcmarkup tool, not xml2rfc. -- ---------------------------------------------+----------------------------- Reporter: magnus.westerlund@ericsson.com | Owner: Type: defect | henrik@levkowetz.com Priority: medium | Status: closed Component: Version 2 cli | Milestone: Resolution: invalid | Version: 2.4.x | Keywords: ---------------------------------------------+----------------------------- Ticket URL: xml2rfc From nobody Thu Jun 18 15:36:09 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE971A907E for ; Thu, 18 Jun 2015 15:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGsHp3ZwdwWb for ; Thu, 18 Jun 2015 15:36:06 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9022B1A9030 for ; Thu, 18 Jun 2015 15:36:06 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Z5iPl-0008dw-Li for xml2rfc@ietf.org; Thu, 18 Jun 2015 18:36:05 -0400 Date: Thu, 18 Jun 2015 18:36:00 -0400 From: John C Klensin To: xml2rfc@ietf.org Message-ID: <1C0F4C4D399B529FE0B9FAD3@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [xml2rfc] How to spell "electronic mail" X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 22:36:08 -0000 Hi. This is the sort of thing about which most of our eyes glaze over, resulting in our not noticing, especially when it is buried in a section that no one typically reads. But it has just come to my attention, via an AUTH48 diff, that different versions of xml2rfc are spelling the information that comes out of the element of differently, with some putting "Email:" into the Author's Address (or equivalent) section and others generating "EMail:". Despite the observation that I haven't noticed this and have therefore let the latter slip through into several RFCs with my name on it and because we are now in a period of reviewing formats, tags, and outputs, I find "EMail" really obnoxious. I can imagine absolutely no reason for the oddly-cased characters. Perhaps it would be justified if we routinely wrote "Electronic Mail" or "electronic Mail" rather than "electronic mail", but we don't. Perhaps it would be justified if we wanted to distinguish "our" email from claims by various people to have invented "Email" a decade or more after many of us were using it regularly, but I don't think we need to do that and it is too subtle anyway. It would certainly be justified if the core Internet mail specifications represented by RFC 5322 and 5321 used the term normatively with that spelling, but 5321 doesn't use the term at all except in the contact information and 5322 uses "email" in its Acknowledgments section, then switches (as does 5321) to "EMail" in the contact information. That form might also be justified if it were intended to call the reader's attention to some special or unusual form of electronic mail, e.g,, if what was being written was MegoCorpMail: but that doesn't apply either, especially since the IETF's implicit position for many years is that we define Internet mail and this is it. It may or may not be relevant that we have other references that use much more simple forms. For example, the "mailto:" URL just uses "mailto", not "emailto", much less adopting a conventionalized spelling of EMailTo or something like that. Historically, as a last and lamented colleague was fond of pointing out, we called it "net mail" for many years before "electronic mail" took over. Without at least one of the above justifications or something equivalent to it, "EMail" is distracting, fussy, violates every style manual entry for English capitalization I can find, and makes authors and/or the RFC Editor look silly. I can't speak for the RFC Editor, but I usually prefer designations other than "silly". Can we make this thoroughly-contrived spelling go away when the rendering systems are next opened? best, john From nobody Thu Jun 18 16:22:35 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5891A90B4 for ; Thu, 18 Jun 2015 16:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2vy_8Gfnc8t for ; Thu, 18 Jun 2015 16:22:33 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122AC1A90BB for ; Thu, 18 Jun 2015 16:22:29 -0700 (PDT) Received: by oigb199 with SMTP id b199so27134288oig.3 for ; Thu, 18 Jun 2015 16:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-type; bh=s6XZt/vCA+j74DW8N1slfKjrmsc49bITsnayTZ1lj5U=; b=kneOUiSYs9W/JoG+jTdpkSabh47o5uG24Oq+jJHDz4w0vLfllQFjyYAHtoqOI/kqF0 jZoKCVi/cK//2+2EFRHTQHgTaYiSsyvKjSH25GR0XgPjwl3vRpcZ6Favoy7yYKAIF0MM fshbIbwIfF1vt9DAa1SJUJXUzvyngQ6kka7ak= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-type; bh=s6XZt/vCA+j74DW8N1slfKjrmsc49bITsnayTZ1lj5U=; b=FCqvxcDNR7tDf3NlQRvzKgqpz7D5gvn1WBWXdIe2ksLxrwfpDg2VX0IHkc/zQFc7/Q 1YGVsXO2FfKbfwFB/IWNqM4zuByn1LopRhn+yygJeERgXjXAL/79DEk71DnNBEeIFbin id2KxglX7zoywxc2vWQPoQScCyPzwODxa+K4vsIT2UMqTf64DedLFyzOXrCgxKFpq1wZ sDw+R0gA+SvBm3eU5do0i+o8lIzbf3GyithHmCXBZAQ1k/2bT51zZb3Xejl7ZkSPALvj ba+4K+HeqQV1sekLcmw9L1u+o+WQIc+Hyy1YL9544esErjqXekZdgAU0rp8A5cIPHMoe MQgg== X-Gm-Message-State: ALoCoQkY4bOZWNC3jF3IVmedn5/RHItaFfV4nYY0bOx4RsBfsSw0LdCLUQySdpDk1qebDpIhrnkB X-Received: by 10.202.219.195 with SMTP id s186mr10475197oig.25.1434669748420; Thu, 18 Jun 2015 16:22:28 -0700 (PDT) From: Joe Abley Mime-Version: 1.0 (1.0) References: <1C0F4C4D399B529FE0B9FAD3@JcK-HP8200.jck.com> In-Reply-To: <1C0F4C4D399B529FE0B9FAD3@JcK-HP8200.jck.com> Date: Thu, 18 Jun 2015 19:22:27 -0400 Message-ID: <4181354708537052696@unknownmsgid> To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "xml2rfc@ietf.org" Subject: Re: [xml2rfc] How to spell "electronic mail" X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 23:22:34 -0000 On Jun 18, 2015, at 18:36, John C Klensin wrote: > Without at least one of the above justifications or something > equivalent to it, "EMail" is distracting, fussy, violates every > style manual entry for English capitalization I can find, and > makes authors and/or the RFC Editor look silly. I can't speak > for the RFC Editor, but I usually prefer designations other than > "silly". > > Can we make this thoroughly-contrived spelling go away when the > rendering systems are next opened? I think "EMail" is worse than "Email", which presumably would be "email" when it's not starting a sentence or hanging out with its friends in a title. But to be honest, I don't like "email" either. My brain wants to read it as "emmail", because when else is an e in a word sounded by name rather than its sound? And if we're following the rules, such as they are, wouldn't that make it "Eemail"? I generally keep quiet about this, as I have learned to do when North Americans pronounce the name Xavier. At least "EMail" makes you stop and prepare yourself emotionally for something weird. Probably I just have a confused and fussy view following early life in too many, different, English-speaking countries, but to me it will always be e-mail, easily defensible by comparison with x-ray. Joe From nobody Thu Jun 18 17:01:37 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707B11B2DB4 for ; Thu, 18 Jun 2015 17:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drNxVT9i2JMR for ; Thu, 18 Jun 2015 17:01:35 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACFA51B2DD1 for ; Thu, 18 Jun 2015 16:58:59 -0700 (PDT) Received: (qmail 70068 invoked from network); 18 Jun 2015 23:59:09 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 18 Jun 2015 23:59:09 -0000 Date: 18 Jun 2015 23:58:36 -0000 Message-ID: <20150618235836.80554.qmail@ary.lan> From: "John Levine" To: xml2rfc@ietf.org In-Reply-To: <4181354708537052696@unknownmsgid> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [xml2rfc] How to spell "electronic mail" X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 00:01:35 -0000 >Probably I just have a confused and fussy view following early life in >too many, different, English-speaking countries, but to me it will >always be e-mail, easily defensible by comparison with x-ray. What he said, and my background is purely American. R's, John From nobody Thu Jun 18 18:38:43 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AEA1A0385 for ; Thu, 18 Jun 2015 18:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpfCE8GKYO6I for ; Thu, 18 Jun 2015 18:38:41 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8461A011D for ; Thu, 18 Jun 2015 18:38:41 -0700 (PDT) Received: by pdbci14 with SMTP id ci14so20200697pdb.2 for ; Thu, 18 Jun 2015 18:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pqQ16dfBsHupurFN73Z15fCbMCZTx6uYNhXUkmDUiXU=; b=vXlgLZGAkc6zhezgiw96OT3IKPrifPmxi7E3IeIxw7EeO8uS7PBtPTKBVnmeQ0FC7j cEVfLdazlGnIRxuCJ6mZ+Xh2y6qMYuQVvlRJ2yLBjdhrzVtvRrLpDsYXxnNIbayoTrBt O1kwmcfGPUxpxf+bGQ9zTPsz8EgyGgsN/So0JzJtf6NdAwE24nX5dDwFU336YH489hlh AEW9tbkmwDDAeIUSy3Unkhtf5O5liMYOMX5FQCMxYuXMwvlZmNmfuGo2DC6bCLILLdMV 0Y5l3XVEGzr/duSScsaAtpHwd7JxLzgI9RPA2GHZA2kxbjG2qw5tL8cAer+rXo3SAls8 11vw== X-Received: by 10.70.134.170 with SMTP id pl10mr26773097pdb.132.1434677921183; Thu, 18 Jun 2015 18:38:41 -0700 (PDT) Received: from ?IPv6:2406:e007:4c72:1:28cc:dc4c:9703:6781? ([2406:e007:4c72:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id qt4sm9259365pbc.86.2015.06.18.18.38.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2015 18:38:40 -0700 (PDT) Message-ID: <558372A6.1060201@gmail.com> Date: Fri, 19 Jun 2015 13:38:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: xml2rfc@ietf.org References: <20150618235836.80554.qmail@ary.lan> In-Reply-To: <20150618235836.80554.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] How to spell "electronic mail" X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 01:38:42 -0000 On 19/06/2015 11:58, John Levine wrote: >> Probably I just have a confused and fussy view following early life in= >> too many, different, English-speaking countries, but to me it will >> always be e-mail, easily defensible by comparison with x-ray. >=20 > What he said, and my background is purely American. Email is particularly confusing to francophones. Definition of email > (t=C3=A9l=C3=A9communications) courrier =C3=A9lectronique, envoy=C3=A9 = via Internet Definition of =C3=A9mail > (technologie) substance vitreuse color=C3=A9e au moyen d'oxydes m=C3=A9= talliques que l'on applique =C3=A0 froid sur une pi=C3=A8ce puis que l'on= porte au four pour qu'elle se fixe et se solidifie=20 From nobody Thu Jun 18 19:17:41 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A641A897F for ; Thu, 18 Jun 2015 19:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXkN4TgKd7At for ; Thu, 18 Jun 2015 19:17:38 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F241A899A for ; Thu, 18 Jun 2015 19:17:38 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Z5ls8-0009nx-KB; Thu, 18 Jun 2015 22:17:36 -0400 Date: Thu, 18 Jun 2015 22:17:31 -0400 From: John C Klensin To: Joe Abley Message-ID: <8395727E78FDC3339DAA0D19@JcK-HP8200.jck.com> In-Reply-To: <4181354708537052696@unknownmsgid> References: <1C0F4C4D399B529FE0B9FAD3@JcK-HP8200.jck.com> <4181354708537052696@unknownmsgid> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: xml2rfc@ietf.org Subject: Re: [xml2rfc] How to spell "electronic mail" X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 02:17:40 -0000 --On Thursday, June 18, 2015 19:22 -0400 Joe Abley wrote: > On Jun 18, 2015, at 18:36, John C Klensin > wrote: > >> Without at least one of the above justifications or something >> equivalent to it, "EMail" is distracting, fussy, violates >> every style manual entry for English capitalization I can >> find, and makes authors and/or the RFC Editor look silly. I >> can't speak for the RFC Editor, but I usually prefer >> designations other than "silly". >> >> Can we make this thoroughly-contrived spelling go away when >> the rendering systems are next opened? > > I think "EMail" is worse than "Email", which presumably would > be "email" when it's not starting a sentence or hanging out > with its friends in a title. > > But to be honest, I don't like "email" either. My brain wants > to read it as "emmail", because when else is an e in a word > sounded by name rather than its sound? And if we're following > the rules, such as they are, wouldn't that make it "Eemail"? I > generally keep quiet about this, as I have learned to do when > North Americans pronounce the name Xavier. At least "EMail" > makes you stop and prepare yourself emotionally for something > weird. > > Probably I just have a confused and fussy view following early > life in too many, different, English-speaking countries, but > to me it will always be e-mail, easily defensible by > comparison with x-ray. I have argued for "email" only because that spelling, independent of case, seems to be prevalent in IETF documents. But I'm at least equally fine with e-mail, if that is what the community wants to use going forward (I'd be happy returning to "net mail" too, if only because faxes are, if one feels literal about it, ".electronic mail"). But I still find "EMail", which is what some versions of xml2rfc are apparently producing, offensive (and would find "e-Mail" or "E-Mail" no less so). john From nobody Fri Jun 19 09:37:43 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677E81AC419 for ; Fri, 19 Jun 2015 09:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I46V_5SkwB2V for ; Fri, 19 Jun 2015 09:37:41 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBA31AC418 for ; Fri, 19 Jun 2015 09:37:41 -0700 (PDT) Received: (qmail 16151 invoked from network); 19 Jun 2015 16:37:50 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 Jun 2015 16:37:50 -0000 Date: 19 Jun 2015 16:37:17 -0000 Message-ID: <20150619163717.84513.qmail@ary.lan> From: "John Levine" To: xml2rfc@ietf.org In-Reply-To: <558372A6.1060201@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [xml2rfc] How to spell "electronic mail" X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 16:37:42 -0000 >> What he said, and my background is purely American. > >Email is particularly confusing to francophones. Ouais. In French, what we call e-mail is called "courriel", a portmanteau of courrier électronique. What we call spam is in Québec called pourriel, a pun on "pourri" meaning rotten. That is too clever for European francophones who call it "le spam". R's, John From nobody Fri Jun 19 10:59:59 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B9B1ACE1D for ; Fri, 19 Jun 2015 10:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2AAjap5YYGG for ; Fri, 19 Jun 2015 10:59:56 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5F51ACE1B for ; Fri, 19 Jun 2015 10:59:56 -0700 (PDT) Received: from [172.27.129.47] ([131.90.138.147]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t5JHxq8E023182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Jun 2015 10:59:55 -0700 Message-ID: <55845897.70603@dcrocker.net> Date: Fri, 19 Jun 2015 10:59:51 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: John C Klensin , xml2rfc@ietf.org References: <1C0F4C4D399B529FE0B9FAD3@JcK-HP8200.jck.com> In-Reply-To: <1C0F4C4D399B529FE0B9FAD3@JcK-HP8200.jck.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 19 Jun 2015 10:59:56 -0700 (PDT) Archived-At: Subject: Re: [xml2rfc] How to spell "electronic mail" X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 17:59:57 -0000 On 6/18/2015 3:36 PM, John C Klensin wrote: > Hi. hmm. you didn't type "hi". I guess captialization is ok, sometimes... There are two different issues that ought to affect the choices. One is the 'word' and the second is the effect of context. "email" has become a formally accepted word. Debating its legitimacy is 10-15 years past debate. Context affects choosing mail vs. email. The term 'mail' can be ambiguous, given at least the choice between electronic and postal. Using the term 'mail' without a qualifier makes sense only when the context constrains the meaing. Citing mailto doesn't help; it's an artificial, technical context that defined its uses. The lesson to learn from this case is that self-contained contexts get to choose whatever the definers want. Natural language contexts have their own rules and we should follow them. So if this is a form -- I'm assuming the xml2rfc context is best thought of as a form -- capitalize if that's what is being done. Don't if it isn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jun 19 11:57:11 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E661ACF03 for ; Fri, 19 Jun 2015 11:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDx0yVhwtxIB for ; Fri, 19 Jun 2015 11:57:09 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5F91AC3FC for ; Fri, 19 Jun 2015 11:57:09 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id E0E0B6B0084; Fri, 19 Jun 2015 11:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=nI5/UgO46zgRtW 8/gQ2cxc7SBb0=; b=gn1HM8GFhVqiLZjtSUhSL1QZZWBcS2XsbrbpZ4KhNRCBzT uU4BMTVeyMg529zanz+WYsx4QpCNJ1/ZuWFMD35WI6XJWTXLrA4PJxyQM1kFIGeK /ZRWaN4FK8OXHaP/zOKurKyUXlj6cBPG3VM3OEXWQywYVNZWgnKlbsJ1uLSC0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPA id 1EA266B0082; Fri, 19 Jun 2015 11:57:08 -0700 (PDT) Date: Fri, 19 Jun 2015 13:57:07 -0500 From: Nico Williams To: dcrocker@bbiw.net Message-ID: <20150619185706.GF6117@localhost> References: <1C0F4C4D399B529FE0B9FAD3@JcK-HP8200.jck.com> <55845897.70603@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55845897.70603@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: John C Klensin , xml2rfc@ietf.org Subject: Re: [xml2rfc] How to spell "electronic mail" X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 18:57:10 -0000 On Fri, Jun 19, 2015 at 10:59:51AM -0700, Dave Crocker wrote: > Context affects choosing mail vs. email. The term 'mail' can be > ambiguous, given at least the choice between electronic and postal. > Using the term 'mail' without a qualifier makes sense only when the > context constrains the meaing. We could say "mail" for the electronic variant, and "pmail" for the pony express variety. From nobody Fri Jun 19 12:28:08 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F360B1AD34D for ; Fri, 19 Jun 2015 12:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgpyRht33Nse for ; Fri, 19 Jun 2015 12:28:04 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4FA1AD333 for ; Fri, 19 Jun 2015 12:28:04 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Z61xL-000Dtz-Dp; Fri, 19 Jun 2015 15:28:03 -0400 Date: Fri, 19 Jun 2015 15:27:58 -0400 From: John C Klensin To: dcrocker@bbiw.net, xml2rfc@ietf.org Message-ID: In-Reply-To: <55845897.70603@dcrocker.net> References: <1C0F4C4D399B529FE0B9FAD3@JcK-HP8200.jck.com> <55845897.70603@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] How to spell "electronic mail" X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 19:28:06 -0000 --On Friday, June 19, 2015 10:59 -0700 Dave Crocker wrote: > On 6/18/2015 3:36 PM, John C Klensin wrote: >> Hi. > > hmm. you didn't type "hi". I guess captialization is ok, > sometimes... > > There are two different issues that ought to affect the > choices. > > One is the 'word' and the second is the effect of context. > > "email" has become a formally accepted word. Debating its > legitimacy is 10-15 years past debate. Indeed, and I didn't suggest that we do that. > Context affects choosing mail vs. email. The term 'mail' can > be ambiguous, given at least the choice between electronic and > postal. Using the term 'mail' without a qualifier makes sense > only when the context constrains the meaing. For the specific context of the question -- and I think I was being quite specific that I was talking about the identifying label created in output text in response to an element subsidiary to an element in xml2rfc -- the context is, I think, very clear. Presumably the number of postal addresses in the world that look like, e.g., "dcrocker@bbiw.net" makes the context even more clear. > Citing mailto doesn't help; it's an artificial, technical > context that defined its uses. The lesson to learn from this > case is that self-contained contexts get to choose whatever > the definers want. Natural language contexts have their own > rules and we should follow them. ok. > So if this is a form -- I'm assuming the xml2rfc context is > best thought of as a form -- capitalize if that's what is > being done. Don't if it isn't. The issue isn't whether "email:" is written that way before the relevant data or it is written "Email:". Personally, I prefer the latter for exactly the reasons you cite, e.g., we spell out "Phone:" and capitalize it (and, by more or less arbitrary convention, don't spell it "Tel:" or "Telephone:", which would presumably be equally reasonable. What I was objecting to was (and is) versions of XML2RFC (apparently including the one the RFC Editor is using) that, instead of putting "Email:" into that position (which some, including the current online version, do), are spelling it "EMail:", a form that has certainly not been widely accepted, much less for 10-15 years or longer. And the "natural language context" certainly doesn't predict to it either. john From nobody Fri Jun 19 18:54:10 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93B31B2C80 for ; Fri, 19 Jun 2015 18:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbbvgBHZMoHm for ; Fri, 19 Jun 2015 18:54:08 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFEC01B2C7F for ; Fri, 19 Jun 2015 18:54:08 -0700 (PDT) Received: from [172.28.2.94] ([131.90.56.39]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t5K1s5RL007878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Jun 2015 18:54:08 -0700 Message-ID: <5584C7BC.7060109@dcrocker.net> Date: Fri, 19 Jun 2015 18:54:04 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: John C Klensin , xml2rfc@ietf.org References: <1C0F4C4D399B529FE0B9FAD3@JcK-HP8200.jck.com> <55845897.70603@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 19 Jun 2015 18:54:08 -0700 (PDT) Archived-At: Subject: Re: [xml2rfc] How to spell "electronic mail" X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 01:54:10 -0000 On 6/19/2015 12:27 PM, John C Klensin wrote: > The issue isn't whether "email:" is written that way before the > relevant data or it is written "Email:". ... > What I was objecting to was (and is) versions of XML2RFC > (apparently including the one the RFC Editor is using) that, > instead of putting "Email:" into that position (which some, > including the current online version, do), are spelling it > "EMail:", a form that has certainly not been widely accepted, > much less for 10-15 years or longer. And the "natural language > context" certainly doesn't predict to it either. So you're essentially lodging a bug report: The correct presentation rendering of the field name for should be "Email:". Some versions render it as "EMail:". This creates an inconsistency; and this should be treated as a bug. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jun 20 00:08:40 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E259F1A1BCC for ; Sat, 20 Jun 2015 00:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPXHnmCJjmXD for ; Sat, 20 Jun 2015 00:08:37 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6463E1A1B7A for ; Sat, 20 Jun 2015 00:08:37 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Z6CtH-000LkV-If; Sat, 20 Jun 2015 03:08:35 -0400 Date: Sat, 20 Jun 2015 03:08:30 -0400 From: John C Klensin To: dcrocker@bbiw.net, xml2rfc@ietf.org Message-ID: In-Reply-To: <5584C7BC.7060109@dcrocker.net> References: <1C0F4C4D399B529FE0B9FAD3@JcK-HP8200.jck.com> <55845897.70603@dcrocker.net> <5584C7BC.7060109@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] How to spell "electronic mail" X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 07:08:39 -0000 --On Friday, June 19, 2015 18:54 -0700 Dave Crocker wrote: > On 6/19/2015 12:27 PM, John C Klensin wrote: >> The issue isn't whether "email:" is written that way before >> the relevant data or it is written "Email:". > ... >> What I was objecting to was (and is) versions of XML2RFC >> (apparently including the one the RFC Editor is using) that, >> instead of putting "Email:" into that position (which some, >> including the current online version, do), are spelling it >> "EMail:", a form that has certainly not been widely accepted, >> much less for 10-15 years or longer. And the "natural >> language context" certainly doesn't predict to it either. > So you're essentially lodging a bug report: > > The correct presentation rendering of the field name for > should be "Email:". Some versions render it as > "EMail:". This creates an inconsistency; and this should be > treated as a bug. That may very well be. I decided to try to raise the question more broadly because one of the versions (or profiles or style sheets -- I don't know which) that is producing "EMail:" is the RFC Editor's version/ style sheet. Because of that, I'm not sure whether this is a bug in the code/ versioning or an, IMO, particularly ill-advised policy decision (both because I think the spelling is wrong and because gratuitous differences between I-D conventions, format, and layout and their RFC counterpart are probably a bad idea. john From nobody Sat Jun 20 09:21:20 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32061A88C6 for ; Sat, 20 Jun 2015 09:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xiggrBbkc5a for ; Sat, 20 Jun 2015 09:21:13 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835A51A88C5 for ; Sat, 20 Jun 2015 09:21:13 -0700 (PDT) Received: from [172.28.66.170] (host185164.pge.com [131.89.185.164]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t5KGL925003273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 20 Jun 2015 09:21:12 -0700 Message-ID: <558592F4.209@dcrocker.net> Date: Sat, 20 Jun 2015 09:21:08 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: John C Klensin , xml2rfc@ietf.org References: <1C0F4C4D399B529FE0B9FAD3@JcK-HP8200.jck.com> <55845897.70603@dcrocker.net> <5584C7BC.7060109@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 20 Jun 2015 09:21:13 -0700 (PDT) Archived-At: Subject: Re: [xml2rfc] How to spell "electronic mail" X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 16:21:17 -0000 On 6/20/2015 12:08 AM, John C Klensin wrote: > Because of that, I'm not > sure whether this is a bug in the code/ versioning or an, IMO, > particularly ill-advised policy decision (both because I think > the spelling is wrong and because gratuitous differences between > I-D conventions, format, and layout and their RFC counterpart > are probably a bad idea. I tried to choose wording that makes this distinction irrelevant. It specifies a 'proper' representation. It calls for conformance to that representation. If anyone wants to take issue with either of these, they can, but both points are simple and discrete; ie, separable. So, for example, debating group preference between Email and EMail is separate from a possible debate about whether all IETF-related renderings should use the same string. So we can establish a clear and stable base of the 'technical' detail, and then worry about enforcement. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 22 14:30:17 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C85F1AD33F for ; Mon, 22 Jun 2015 14:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JNHn5Hqzeln for ; Mon, 22 Jun 2015 14:30:14 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F8F1AD366 for ; Mon, 22 Jun 2015 14:30:11 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 36e78855.0.5109699.00-2274.14441612.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 22 Jun 2015 21:30:12 +0000 (UTC) X-MXL-Hash: 55887e64191f3be9-caeb62256137ef31ba5c6a1bd77a1c4a4dfbe6f4 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5MLUBQx032396 for ; Mon, 22 Jun 2015 17:30:11 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5MLU4Ow031034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 22 Jun 2015 17:30:08 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for ; Mon, 22 Jun 2015 21:29:44 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5MLTiWt022870 for ; Mon, 22 Jun 2015 17:29:44 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5MLTfhW022743 for ; Mon, 22 Jun 2015 17:29:42 -0400 Received: from tonys-macbook-pro.local (unknown[135.110.240.150](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150622212940gw1000cejie>; Mon, 22 Jun 2015 21:29:41 +0000 X-Originating-IP: [135.110.240.150] Message-ID: <55887E44.2090509@att.com> Date: Mon, 22 Jun 2015 17:29:40 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: xml2rfc@ietf.org References: <1C0F4C4D399B529FE0B9FAD3@JcK-HP8200.jck.com> <55845897.70603@dcrocker.net> <5584C7BC.7060109@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=fYAaPTsF c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=tHvJy1wsfNMA:10 a=pLFOALEdaWwA:10 a=BLceEmwcHowA:10 a=N65] X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=XAFQembCKUMA:10 a=C2ENTiL9] X-AnalysisOut: [32vyZJJjSXIA:9 a=pILNOxqGKmIA:10 a=YqZKw9jG1CwK1Bxv:21 a=p] X-AnalysisOut: [kqnxG6zerwHeC6Q:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [xml2rfc] How to spell "electronic mail" X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 21:30:15 -0000 There is an rfcedstyle processing instruction that the RFC Editor sets before processing the XML files. One aspect of that mode is the spelling EMail. =46rom Marshall's original README: "rfcedstyle yes attempt to closely follow finer details from the latest observable RFC-Editor style so as to minimize the probability of being sent back corrections after submission; = = = =20 this directive is a kludge whose exact behavior is likely to change on a regular basis to match the current flavor of the month; = = = =20 presently, it will capitalize the adjective "This" in automatically generated headings, use the variant "acknowledgement" spelling instead of Merriam Webster's main "acknowledgment" dictionary entry, use the "eMail" spelling instead of Knuth's more modern "email" spelling, only put one blank line instead of two before top sections, omit "Intellectual Property and Copyright Statements" and "Author's Address" from the table of content, and not limit the indentation to a maximum tag length in sections." I'm pretty certain that the v2 xml2rfc does likewise. Tony Hansen On 6/20/15 3:08 AM, John C Klensin wrote: > > That may very well be. I decided to try to raise the question > more broadly because one of the versions (or profiles or style > sheets -- I don't know which) that is producing "EMail:" is the > RFC Editor's version/ style sheet. Because of that, I'm not > sure whether this is a bug in the code/ versioning or an, IMO, > particularly ill-advised policy decision (both because I think > the spelling is wrong and because gratuitous differences between > I-D conventions, format, and layout and their RFC counterpart > are probably a bad idea. From nobody Tue Jun 23 17:16:42 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6DE1B30D9 for ; Tue, 23 Jun 2015 17:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftJbufKQGrlt for ; Tue, 23 Jun 2015 17:16:40 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A958F1B30D8 for ; Tue, 23 Jun 2015 17:16:40 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Z7YMp-0001yX-6G for xml2rfc@ietf.org; Wed, 24 Jun 2015 00:16:39 +0000 Date: Wed, 24 Jun 2015 09:16:37 +0900 Message-ID: From: Randy Bush To: XML2RFC Interest Group User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [xml2rfc] refs for 7115, for example X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 00:16:41 -0000 i rsync from rsync.tools.ietf.org::xml2rfc.bibxml/bibxml. i seem to have no refs for rfc7115, for example. clue bat, please. randy From nobody Tue Jun 23 19:13:47 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EB11B33AA for ; Tue, 23 Jun 2015 19:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJE-7SsN9ORl for ; Tue, 23 Jun 2015 19:13:34 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9520B1B33A1 for ; Tue, 23 Jun 2015 19:13:34 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id d421a855.0.5736507.00-2358.16221731.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 24 Jun 2015 02:13:34 +0000 (UTC) X-MXL-Hash: 558a124e27bc138c-56f51d22ada06768f329d5a041b8c3b12608d170 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5O2DWAU027323 for ; Tue, 23 Jun 2015 22:13:32 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5O2DQwI027299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 23 Jun 2015 22:13:28 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor) for ; Wed, 24 Jun 2015 02:13:15 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5O2DFNK026265 for ; Tue, 23 Jun 2015 22:13:15 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5O2D97x025963 for ; Tue, 23 Jun 2015 22:13:09 -0400 Received: from tonys-macbook-pro.local (unknown[135.110.241.92](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150624021306gw1000cejpe>; Wed, 24 Jun 2015 02:13:09 +0000 X-Originating-IP: [135.110.241.92] Message-ID: <558A1231.8070406@att.com> Date: Tue, 23 Jun 2015 22:13:05 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Randy Bush , XML2RFC Interest Group References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=bsn78jmi c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=tHvJy1wsfNMA:10 a=gnyLn44jPBwA:10 a=BLceEmwcHowA:10 a=N65] X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=XAFQembCKUMA:10 a=48vgC7mU] X-AnalysisOut: [AAAA:8 a=0y8Nah-Paeb3qmPL3GMA:9 a=pILNOxqGKmIA:10 a=wSJY_n] X-AnalysisOut: [QxIZMA:10 a=d4Xho0I27voA:10 a=sfUVGbASsqUA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [xml2rfc] refs for 7115, for example X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 02:13:40 -0000 On 6/23/15 8:16 PM, Randy Bush wrote: > i rsync from rsync.tools.ietf.org::xml2rfc.bibxml/bibxml. i seem to > have no refs for rfc7115, for example. clue bat, please. I don't know. http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7115.xml appears to be alive and well. Tony Hansen From nobody Tue Jun 23 19:44:11 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FEC1B33F0 for ; Tue, 23 Jun 2015 19:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiP1HvlUNXMc for ; Tue, 23 Jun 2015 19:44:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7931B33EE for ; Tue, 23 Jun 2015 19:44:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Z7afR-0002iS-Vm; Wed, 24 Jun 2015 02:44:02 +0000 Date: Wed, 24 Jun 2015 11:44:00 +0900 Message-ID: From: Randy Bush To: Tony Hansen In-Reply-To: <558A1231.8070406@att.com> References: <558A1231.8070406@att.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: multipart/mixed; boundary="Multipart_Wed_Jun_24_11:43:58_2015-1" Content-Transfer-Encoding: 8bit Archived-At: Cc: XML2RFC Interest Group Subject: Re: [xml2rfc] refs for 7115, for example X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 02:44:09 -0000 --Multipart_Wed_Jun_24_11:43:58_2015-1 Content-Type: text/plain; charset=US-ASCII xml2rfc draft-ietf-sidr-bgpsec-ops.xml --html --text Parsing file draft-ietf-sidr-bgpsec-ops.xml ERROR: Unable to parse the XML document: draft-ietf-sidr-bgpsec-ops.xml draft-ietf-sidr-bgpsec-ops.xml: Line 376: Unable to resolve external request: "reference.RFC.7115" make: *** [all] Error 1 document appended. it passes fenron's validator. i am just being blind. and is there a current macintosh binary? randy --Multipart_Wed_Jun_24_11:43:58_2015-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="draft-ietf-sidr-bgpsec-ops.xml" Content-Transfer-Encoding: 8bit BGPsec Operational Considerations Internet Initiative Japan

5147 Crystal Springs Bainbridge Island Washington 98110 US randy@psg.com

Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. It is expected to evolve as BGPsec is formalized and initially deployed. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 only when they appear in all upper case. They may also appear in lower or mixed case as English words, without normative meaning.

BGPsec, , is a new protocol with many operational considerations. It is expected to be deployed incrementally over a number of years. As core BGPsec-capable routers may require large memory and/or modern CPUs, it is thought that origin validation based on the RPKI, , will occur over the next twp to three years and that BGPsec will start to deploy well after that. BGPsec relies on widespread propagation of the Resource Public Key Infrastructure (RPKI) . How the RPKI is distributed and maintained globally and within an operator's infrastructure may be different for BGPsec than for origin validation. BGPsec need be spoken only by an AS's eBGP speaking, AKA border, routers, and is designed so that it can be used to protect announcements which are originated by small edge routers. This has special operational considerations. Different prefixes may have different timing and replay protection considerations.

It is assumed that the reader understands BGP, , BGPsec, , the RPKI, see , the RPKI Repository Structure, see , and ROAs, see .

All non-ROA considerations in the section on RPKI Distribution and Maintenance of apply.

As described in BGPsec-speaking routers are be capable of generating their own public/private key-pairs and having their certificates signed and published in the RPKI by the RPKI CA system, and/or are given public/private key-pairs by the operator. A site/operator MAY use a single certificate/key in all their routers, one certificate/key per router, or any granularity in between. A large operator, concerned that a compromise of one router's key would make other routers vulnerable, MAY accept a more complex certificate/key distribution burden to reduce this exposure. On the other extreme, an edge site with one or two routers may choose to use a single certificate/key. In anticipation of possible key compromise, a prudent operator will pre-provision each router's 'next' key in the RPKI so there is no propagation delay for provisioning the new key.

BGPsec is spoken by edge routers in a network, those which border other networks/ASs. In a fully BGPsec enabled AS, Route Reflectors MUST have BGPsec enabled if and only if there are eBGP speakers in their client cone, i.e. an RR client or the transitive closure of their customers' customers' customers' .... A BGPsec capable router MAY use the data it receives to influence local policy within its network, see . In deployment this policy should fit into the AS's existing policy, preferences, etc. This allows a network to incrementally deploy BGPsec enabled border routers. eBGP speakers which face more critical peers or up/downstreams would be candidates for early deployment. Both securing one's own announcements and validating received announcements should be considered in partial deployment. The operator should be aware that BGPsec, as any other policy change, can cause traffic shifts in their network. And, as with normal policy shift practice, a prudent operator has tools and methods to predict, measure, modify, etc. On the other hand, an operator wanting to monitor router loading, shifts in traffic, etc. might deploy incrementally while watching those and similar effects. As they are not formally verifiable, an eBGP listener SHOULD NOT strongly trust unsigned security markings such as communities received across a trust boundary.

An edge site which does not provide transit and trusts its upstream(s) SHOULD only originate a signed prefix announcement and need not validate received announcements. BGPsec protocol capability negotiation provides for a speaker signing the data it sends without being able to accept signed data. Thus a smallish edge router may hold only its own signing key(s), sign it's announcements, but not receive signed announcements and therefore not need to deal with the majority of the RPKI. Thus such routers CPU, RAM, and crypto needs are trivial and additional hardware should not be needed. As the vast majority (84%) of ASs are stubs, and they announce the majority of prefixes, this allows for simpler and less expensive incremental deployment. It may also mean that edge sites concerned with routing security will be attracted to upstreams which support BGPsec.

Unlike origin validation based on the RPKI, BGPsec marks a received announcement as Valid or Invalid, there is no explicit NotFound state. In some sense, an unsigned BGP4 path is the equivalent of NotFound. How this is used in routing is up to the operator's local policy. See . As BGPsec will be rolled out over years and does not allow for intermediate non-signing edge routers, coverage will be spotty for a long time. Hence a normal operator's policy SHOULD NOT be overly strict, perhaps preferring Valid paths and giving very low preference, but still using, Invalid paths. Operators should be aware that accepting Invalid announcements, no matter how de-preffed, will often be the equivalent of treating them as fully Valid. Consider having a Valid announcement from neighbor V for prefix 10.0.0.0/16 and an Invalid announcement for 10.0.666.0/24 from neighbor I. If local policy on the router is not configured to discard the Invalid announcement from I, then longest match forwarding will send packets to neighbor I no matter the value of local preference. A BGPsec speaker validates signed paths at the eBGP edge. Local policy on the eBGP edge MAY convey the validation state of a BGP signed path through normal local policy mechanisms, e.g. setting a BGP community for internal use, or modifying a metric value such as local-preference or MED. Some may choose to use the large Local-Pref hammer. Others may choose to let AS-Path rule and set their internal metric, which comes after AS-Path in the BGP decision process. Because of possible RPKI version skew, an AS Path which does not validate at router R0 might validate at R1. Therefore, signed paths that are invalid and yet propagated (because they are chosen as best path) SHOULD have their signatures kept intact and MUST be signed if sent to external BGPsec speakers. This implies that updates which a speaker judges to be invalid MAY be propagated to iBGP peers. Therefore, unless local policy ensures otherwise, a signed path learned via iBGP MAY be invalid. If needed, the validation state should be signaled by normal local policy mechanisms such as communities or metrics. On the other hand, local policy on the eBGP edge might preclude iBGP or eBGP announcement of signed AS Paths which are invalid. A BGPsec speaker receiving a path SHOULD perform origin validation per and . If it is known that a BGPsec neighbor is not a transparent route server, and the router provides a knob to disallow a received pCount (prepend count, zero for transparent route servers) of zero, that knob SHOULD be applied. Routers should default to this knob disallowing pCount 0. To prevent exposure of the internals of BGP Confederations , a BGPsec speaker which is a Member-AS of a Confederation MUST NOT sign updates sent to another Member-AS of the same Confederation.

For protection from attacks replaying BGP data on the order of a day or longer old, re-keying routers with new keys (previously) provisioned in the RPKI is sufficient. For one approach, see Like the DNS, the global RPKI presents only a loosely consistent view, depending on timing, updating, fetching, etc. Thus, one cache or router may have different data about a particular prefix or router than another cache or router. There is no 'fix' for this, it is the nature of distributed data with distributed caches. Operators who manage certificates SHOULD have RPKI GhostBuster Records (see ), signed indirectly by End Entity certificates, for those certificates on which others' routing depends for certificate and/or ROA validation. Operators should be aware of impending algorithm transitions, which will be rare and slow-paced, see see . They should work with their vendors to ensure support for new algorithms. As a router must evaluate certificates and ROAs which are time dependent, routers' clocks MUST be correct to a tolerance of approximately an hour. If a router has reason to believe its clock is seriously incorrect, e.g. it has a time earlier than 2011, it SHOULD NOT attempt to validate incoming updates. It SHOULD defer validation until it believes it is within reasonable time tolerance. Servers should provide time service, such as , to client routers.

The major security considerations for the BGPsec protocol are described in .

This document has no IANA Considerations.

--Multipart_Wed_Jun_24_11:43:58_2015-1-- From nobody Tue Jun 23 19:48:16 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3391B33F0 for ; Tue, 23 Jun 2015 19:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0EMQRcfjLGY for ; Tue, 23 Jun 2015 19:48:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2391B31C4 for ; Tue, 23 Jun 2015 19:48:14 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Z7ajV-0002iw-Be; Wed, 24 Jun 2015 02:48:13 +0000 Date: Wed, 24 Jun 2015 11:48:12 +0900 Message-ID: From: Randy Bush To: Tony Hansen In-Reply-To: References: <558A1231.8070406@att.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: XML2RFC Interest Group Subject: Re: [xml2rfc] refs for 7115, for example X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 02:48:15 -0000 sorry, did not intend to post largish file to whole list randy From nobody Wed Jun 24 06:23:40 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FADB1A907B for ; Wed, 24 Jun 2015 06:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WygoYVJcdpms for ; Wed, 24 Jun 2015 06:23:37 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414081A9078 for ; Wed, 24 Jun 2015 06:23:37 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 85faa855.0.5952798.00-2332.16826257.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 24 Jun 2015 13:23:37 +0000 (UTC) X-MXL-Hash: 558aaf5954608ec6-f052e25d23971ba1d508aa0d836b1afddb9e1dda Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5ODNagu005498 for ; Wed, 24 Jun 2015 09:23:36 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5ODNVoe005446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 24 Jun 2015 09:23:31 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for ; Wed, 24 Jun 2015 13:23:08 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5ODN8HP001464 for ; Wed, 24 Jun 2015 09:23:08 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5ODN6bj001291 for ; Wed, 24 Jun 2015 09:23:06 -0400 Received: from tonys-macbook-pro.local (unknown[135.110.241.92](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150624132305gw1000cejre>; Wed, 24 Jun 2015 13:23:05 +0000 X-Originating-IP: [135.110.241.92] Message-ID: <558AAF38.8020101@att.com> Date: Wed, 24 Jun 2015 09:23:04 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Randy Bush References: <558A1231.8070406@att.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=bsn78jmi c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=tHvJy1wsfNMA:10 a=gnyLn44jPBwA:10 a=BLceEmwcHowA:10 a=N65] X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=XAFQembCKUMA:10 a=48vgC7mU] X-AnalysisOut: [AAAA:8 a=2TnQ5W2em2lSK5VB4aQA:9 a=pILNOxqGKmIA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: XML2RFC Interest Group Subject: Re: [xml2rfc] refs for 7115, for example X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 13:23:38 -0000 Randy, I used the xml2rfc.ietf.org website to run xml2rfc and everything worked fine there. There might be a problem with the cache of your local version. Tony On 6/23/15 10:44 PM, Randy Bush wrote: > xml2rfc draft-ietf-sidr-bgpsec-ops.xml --html --text > Parsing file draft-ietf-sidr-bgpsec-ops.xml > ERROR: Unable to parse the XML document: draft-ietf-sidr-bgpsec-ops.xml > draft-ietf-sidr-bgpsec-ops.xml: Line 376: Unable to resolve external request: "reference.RFC.7115" > make: *** [all] Error 1 > > document appended. it passes fenron's validator. i am just being > blind. > > and is there a current macintosh binary? > > randy > From nobody Wed Jun 24 11:07:47 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E66B1ACDD5 for ; Wed, 24 Jun 2015 11:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31359ml2Cg1W for ; Wed, 24 Jun 2015 11:07:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C84E1ACDCB for ; Wed, 24 Jun 2015 11:07:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Z7p5J-0005FM-Sd; Wed, 24 Jun 2015 18:07:42 +0000 Date: Thu, 25 Jun 2015 03:07:40 +0900 Message-ID: From: Randy Bush To: Tony Hansen In-Reply-To: <558AAF38.8020101@att.com> References: <558A1231.8070406@att.com> <558AAF38.8020101@att.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: XML2RFC Interest Group Subject: Re: [xml2rfc] refs for 7115, for example X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 18:07:46 -0000 > Randy, I used the xml2rfc.ietf.org website to run xml2rfc and everything > worked fine there. i did that. and fenron's validator. but still going nuts here ryuu.psg.com:/Users/randy> find refs -name *7115* -exec ls -lg {} \; -rw-rw-r-- 1 staff 666 May 23 2014 refs/rfc/bibxml/rdf/item.RFC.7115.rdf -r--rw-r-- 1 staff 848 May 23 2014 refs/rfc/bibxml/reference.RFC.7115.xml > There might be a problem with the cache of your local version. cache? how do i clear? randy From nobody Wed Jun 24 11:09:39 2015 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE69E1ACDD8 for ; Wed, 24 Jun 2015 11:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mLUvAj0tpDP for ; Wed, 24 Jun 2015 11:09:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9668C1ACDC9 for ; Wed, 24 Jun 2015 11:09:36 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:33386) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z7p78-000MFg-V2; Wed, 24 Jun 2015 14:09:35 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id AF4173FF7C Message-ID: <558AF25E.30805@bbn.com> Date: Wed, 24 Jun 2015 14:09:34 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Randy Bush References: <558A1231.8070406@att.com> <558AAF38.8020101@att.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: XML2RFC Interest Group