NAT/Proxy combinations
Title: Message Generally, people use NAT or Proxy as firewalls. Would it be more secure to use a NAT Proxy combination ? Say, a NAT connected to Proxy connected to NAT. Would this prevent external as well as internal attacks. Also, use static routes between the NAT/proxy/NAT to prevent internal route spoofing. Most proxies I have known are software based and NAT's are firmware based. Assumption being allrequired application level gateways are available for NAT. e.g.Use hardwareNAT's are from two different vendors (with different packet processing algorithm), and proxy is squid. -- Atul ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NAT/Proxy combinations
On 28-aug-2005, at 8:51, Atul Sabharwal wrote: Generally, people use NAT or Proxy as firewalls. Would it be more secure to use a NAT Proxy combination ? Basically, a NAT is just a simple and general-purpose way to implement a proxy. If you define more secure as less likely that random packets will be delivered: sure, put in as much stuff that makes everything less transparent as you can. Obviously this won't help against many popular attack vectors which prey upon the gullibility of the typical user, which mostly happen over HTTP or through mail, which don't need a transparent communication channel. And please don't expect the IETF to make its protocols work through your multiple layers of NAT and proxies. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NAT/Proxy combinations
You might want to look at draft-ietf-v6ops-nap-01.txt Although it is mainly about IPv6, it analyzes aspects of your question. Brian Atul Sabharwal wrote: Generally, people use NAT or Proxy as firewalls. Would it be more secure to use a NAT Proxy combination ? Say, a NAT connected to Proxy connected to NAT. Would this prevent external as well as internal attacks. Also, use static routes between the NAT/proxy/NAT to prevent internal route spoofing. Most proxies I have known are software based and NAT's are firmware based. Assumption being all required application level gateways are available for NAT. e.g. Use hardware NAT's are from two different vendors (with different packet processing algorithm), and proxy is squid. -- Atul ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Dynamic salting in encryption algorithms for peer to peer communication
Title: Message Generally, I have seen that people use PKI or static salts for encrypting data e.g. password. In case of peer to peer communication, would it be useful to use dynamic salts derived from known mathematical series e.g. Fibonacci series, Ramanajum number series. The first salt need not be item(1) of the list but a random item(N) out of a circular series of M items. This could be useful for VPN client/server from same vendor. Web site /Java Applet from a company etc. IsSSL still more secure than dynamic salting for man in the middle attack ? -- Atul ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: language root file size
Last Call: http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04.txt I started documenting some of the problems resulting from the expected size of the language tag registry and the capacity of the langtag solution to fulfill the WG-ltru Charter. Here are two inputs from the author of the Draft above on the WG-ltru list, Doug Ewell: - I've already built a hypothetical RFC 3066ter registry. The changes alone add up to 35,700 lines, or more than 740 pages in RFC format. It might reopen the question of whether an I-D is the best vehicle for delivering this amount of information to IANA. - I still have significant concerns about the assumption that ISO 639-6 will be, or should be, automatically integrated into a language tagging scheme. [snip] Meanwhile, the claim that there are over 20,000 languages to be tagged is being used as an argument against the current RFC 3066bis effort and the plan to support 7,600 languages in RFC 3066ter. I fully share the concerns of Doug Ewell. There is only a difference of timing. I rose questions they took as oppositions and he now discovers as problems. Would the WG-ltru have first analysed its charter we would have identified them a long ago. I list some in annex. The Charter says: The RFC 3066 standard for language tags has been widely adopted in various protocols and text formats, including HTML, XML, and CLDR, [... the first document] is also expected to provide mechanisms to support the evolution of the underlying ISO standards, in particular ISO 639-3, mechanisms to support variant registration and formal extensions, as well as allowing generative private use when necessary. 1. BTW the Charter speaks of adopted _standard_ not of generalised _practice_. 2. the documented upgrade enlarge the size from 80 K (11.5 K zipped) to 650 K (100 K zipped). This information, updates and additions MUST be available to each of the on-line application of the devices of billions of users. The Draft does not explain how. 2. One of the author has _legitimate_ concerns about the capacity of the proposition and the reasonability of the Charter expectation to support the ISO 639-6 evolution of the underlying ISO standards. But he is wrong is in assuming that I use this as an argument against the current RFC 3066bis effort. To the contrary, I use it for a an argument to support the proposed Draft as default solution and support extensions and practical information distribution through other adapted solutions introduced by a singleton. The comment given by Debbie Garside, the author of ISO 639-6 shows there is no concern for our plans and developments using ISO 639-6 [except two months delay on our projected calendar], in line with ISO 11179 (what the WG-ltru and the author if ISO 639-3, Peter Constable, chose to disregard). No problem in specifying this extension capacity through a specialised Draft. If this Draft is a complement, not a competition. But I would prefer to work on a sample ISO 639-6 code and get inputs from the WGIG multilingual forum under discussion. The three approaches (not even alluded by the Charter) address three different layers: - practical, script oriented needs (ISO 639-1, 2, 3, ISO 15924) - comprehensive multimedia, multimodal, multitechnologies and extension to information systems (ISO 639-6) - lingual community networks (privateuse systems) Years of work ahead, I would prefer being made within the IETF rather than against it. jfc Annex: a quick list of questions that need to be addressed. - the nature and the size of the involved information - the size and the frequency of its additions which is not documented. However we know that the I-D bases are just the support for additions. - the availability of this information,addition and updates to the users - the redundancies of this information between three different visions of the language tagging supported by - ISO 639-3: a bare list of 7450 languages calling for variant information - ISO 639-6 : a list of 20.000 pre-formed language tag meant to deliver language information to ISO 11179 systems - the real user systems planned to be supported by the Draft privateuse solution. and their correlations (bridges, equivalence, conflict resolution, etc.) - the additional related information such as locale files (quoted in the Charter as CLDR, the Unicode project to publish all the locales of all the OS directed by one of the authors of the Draft). This related information is actually without limit as it may relates with every other information system (ISO 11179). However efforts like ISO 11179 have not yet addressed two major points: - networking what represents a huge area of research and applications (interoperation of an ISO complete system per... user avatar) - multilingualism, this means that everything supported in ASCII English must be able to be supported in every language - the change in nature of languages,
Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt
Quoting the draft: many of these functions have been taken over by ICANN, ccTLDs and gTLDs RFC 1032 covers that with: until it becomes feasible for other appropriate organizations to assume those responsibilities.. The description of the Nicname/Whois service made there has been obsoleted by RFC 3912 RFC 3912 updates the specification of the WHOIS protocol only. The Whois service provides a contact point for administrative, policy and technical questions about the domain. Although some information in RFC 1032 is dated, it remains useful and is still widely used as a guide for troubleshooting technical issues. The reasons for moving RFC 1032 from status UNKNOWN to status HISTORIC are light. Such a move would have a negative impact on active usage as RFC 3912 does not document the contact point for problems concerning a domain. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Dynamic salting in encryption algorithms for peer to peer communication
Atul Sabharwal wrote: Generally, I have seen that people use PKI or static salts for encrypting data e.g. password. In case of peer to peer communication, would it be useful to use dynamic salts derived from known mathematical series e.g. Fibonacci series, Ramanajum number series. No. Ask on the newsgroup sci.crypt for an explanation of why not; it's not on-topic here. -- David Hopwood [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Tags for Identifying Languages' to BCP
Date: 2005-08-25 20:55 From: JFC (Jefsey) Morfin [EMAIL PROTECTED] the privacy problem is the what you read, who you are intelligence leak. That is to some extent true of any negotiation mechanism and negotiated value. Today langtags are not yet much used (say the W3C people in the WG-ltru) when compared with what they should in XML, HTML, etc. XML, HTML, etc. are not IETF protocols and should not be the main consideration in IETF work on IETF documents, especially as language tags are heavily used by IETF protocols, notably MIME (RFCs 2045, 2047, 2231, 3282) and widely-deployed core IETF application protocols which use MIME (e.g. the Internet Message Format and its applications (email, news, voice messaging, EDI, etc.) and HTTP and applications using HTTP as a substrate. This is all what this proposition is about. This proposition is to give _one_shot_ in a _standardised_ way the language, the script and the country. This was discussed during Last Call of the previous non-IETF (individual submission) attempt. IIRC David Singer brought up several examples of other pieces of information (e.g. legal/copyright variations) that could also be negotiated and which might affect the presentation of content (or choice among alternative content). Lumping all of these separate items into one tag is a poor design as it impedes negotiation and tends toward lengthy tags which are incompatible with fixed-length mechanisms such as MIME encoded-words. While there is some mention of this issue in the document under discussion, its treatment and resolving the underlying issue in a manner that would minimize the problems are lacking. It uses for that ISO codes. ISO never wanted to propose such a code where: ar-arab-us are texts destined the people interested in US Arabic community issues. iw-hebr-ru are texts destined to people interested in Jewish Russian community, etc. When you browser accept that langtags and you pursue the relation, this structured information can be filtered by ISP (for police, censoring, intelligence gathering, etc.) to know about their users. It can be used for searches on a large scale in search engines to know the mail you responded, etc. I suppose that in most of the world countries this is subject to privacy laws. I think that in France it is subject to the anti-racist law (the one used against Yahoo a few years ago). Let's separate three issues: 1. privacy 2. tagging 3. negotiation The privacy issue exists whenever any information is conveyed; the user needs to balance privacy concerns with facilitation of communication. Mechanisms such as TLS can be used to limit the visibility of the information to the end points of communication; ultimately it boils down to a matter of trust in the end-point partner in the communication exchange. I believe that the issue is dealt with adequately in the security considerations section of the document under discussion (some mention of transport-level protection of privacy would be welcome). Tagging identifies characteristics of a particular piece of content. For that purpose alone, it makes little difference (other than regarding the aforementioned compatibility issues with existing IETF mechanisms) whether the characteristics are lumped or separate. There are existing IETF mechanisms which permit handling of either lumped or individual characteristics (e.g. the extensible header field mechanism of RFC 2045 and the feature/filter mechanism of RFC 2533/2738/2912). Tagging per se identifies characteristics of content. While that may be used to infer something about the content provider, such inferences may be unreliable, particularly for providers that support a wide variety of characteristics for the content in question. Negotiation of characteristics is where several issues arise. One such issue, as discussed here in December 2004/January 2005 relates to an algorithm for matching content characteristics (e.g. between a particular piece of content and a specified range of acceptance (as in an RFC 3282 Accept-Language field). RFC 3066 skirted that issue as it stopped short of specification of an algorithm, and as it specified a mere two particular characteristics (language per se, and country) which could be combined in a tag. That was not true of the individual submission, which combined at least 5 characteristics and specified an algorithm. As a result of issues with that approach, the LTRU WG was established with a charter to produce a BCP (for registration procedures) and a separate Standards Track document for topics such as algorithms which are unsuitable for BCP. A related issue is the interaction of the established negotiation mechanism (viz. the RFC 3282 Accept-Language field) and potential use of the other (feature/filter) mechanism for negotiation. The Accept-Language field provides for specification of language ranges and for associating a preference value with specific
Re: Last Call: 'Tags for Identifying Languages' to BCP
Date: 2005-08-25 20:55 From: JFC (Jefsey) Morfin [EMAIL PROTECTED] On 00:40 26/08/2005, David Hopwood said: This objection seems to be correct: URI tags include characters not allowed by RFC 3066. Then? The purpose of this work is to address the limitations of RFC 3066. URI tags did not exist when RFC 3066 was written. RFC 1738 certainly existed, not only at the time of RFC 3066, but its predecessor RFC 1766 as well. please document how do you do, while respecting the hybrid format of the proposed ABNF where information is not indentified by fixed position, but also relative position and size, with - as sole separator. And they want to keep labels between - 8 characters long. Tell me how you support IDNs. Let suppose that I have lang-tags.org: as a scheme. or xn--abcdef.com:. Tell me how you support them It's unclear what you're trying to get at here. A URI scheme is a protocol element (an assigned number) registered by IANA, not a piece of text (see RFCs 1958 and 2277). As such, it has no need of an indication of language, for it has no language; it is a language- independent protocol element. Confusing protocol element issues with language will only muddy the water; try to stay focused on real problems. For that matter, DNS labels are public names (i.e. protocol elements, again see RFC 1958 (sect. 4.3, noting that text there has a different meaning than in RFC 2277)) and as such there should not have been any reason to overload the semantics and baggage of internationalized text (in the RFC 2277 sense). Now, having made the decision to nevertheless do so, you might well point out that per RFC 2277, there ought to be a means of indicating language in IDNs. However, that is primarily an issue with the IDN specification(s), not with the document under discussion (except to the extent that the document under discussion extends the likely length of tags in a way that is likely to conflict with the DNS label length and domain name length limits, *if* there were in fact provision in IDN for the use of language tags. You might also point out that as IDNs use utf-8 exclusively as a charset, and as script is easily inferred from the Unicode code points corresponding to utf-8, that the length-increasing provision for conflating script with language would be unnecessary and redundant *if* IDNs had provision for language tags. But IDNs have no such provision at this time. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02
Date: 2005-08-26 10:45 From: Andrew Newton [EMAIL PROTECTED] If this is the source of the conflict, then BOTH experiments should not use the v=spf1 records. -andy The stated goal of draft-schlitt-spf-classic is to document SPF, basically as it was before the IETF got involved. Yes, the IETF is calling it an experiment, which I don't agree with. It is documenting an existing, well established, protocol. Are you saying that the IETF shouldn't publish an RFC that documents SPF? I stated that the SPF and Sender ID experiments should not use the v=spf1 records to avoid conflict. I did not state that the IETF should not publish an Experimental RFC about SPF. But since you brought this up: if you (the author of the document) do not consider this to be an experiment, then perhaps the IETF should not publish SPF as an Experimental RFC. This is an important point; the SPF-classic draft was announced to the ietf-822 and ietf-smtp mailing lists where there was some discussion on that very point. While the ID-tracker state indicated intended status of Experimental, the author stated that he was very reluctant to debate issues of controversy with the technical specification, and that his goal was to document a de-facto standard [his words]. Both of which would seem to indicate an Informational document, rather than any other category (at least with no apparent mechanism to get to Historic except via the Standards Track -- more below). However, in the same announcement, the author also stated his intent to ask the IESG to consider it for a Proposed Standard status. That conflicts with the ID-tracker state indication and with the stated goal and reluctance to discuss technical shortcomings, and with text in the draft itself which conflicted with BCP 9 procedures. The conflicts in those statements were discussed, copying the IESG. While I agree with the principle that the IESG should not be running concurrent experiments that conflict with one another, there is another principle; the IESG should not be running experiments that are harmful to the Internet, especially when the harm is to those who choose not to participate in the experiment(s). As noted in http://www.imc.org/ietf-smtp/mail-archive/msg01872.html SPF is doubly harmful to the Internet (affecting those who do not explicitly choose to participate); in fairness it should be noted that many of the same considerations also apply to Sender-ID and other similar schemes, however SPF appears to be unique at this time in having the distinction of being more thoroughly adopted by spammers (to lend an air of legitimacy to their missives) than by non-spammers. Because of the harm caused to Internet users who travel, which in turn is due to conflation by many such schemes between sending and receipt of (delivery notification) messages and further conflating the receiving mailboxes with sending IP addresses coupled with the inability of most users to alter the relevant DNS records, neither of the schemes being discussed should have been approved as experiments as written. The IESG should examine both of these schemes -- as well as any others that might be under consideration -- as a result of this appeal. The Historic category of published RFCs can be used for documents which specify a protocol or technology which is known to be harmful to the Internet. However, RFC 2026 appears to have no provision for getting to Historic except via the Standards Track, and we would not want to approve a specification with known technical omissions, harmful provisions, unresolved design choices, and which is not well-understood or suitable for further development as a Proposed Standard solely for the purpose of subsequently moving it to Historic. Perhaps we need another category, or at least a path to Historic that doesn't go via the Standards Track. That is a matter that the IETF should consider, but it seems to be outside of the scope of NEWTRK and other WGs, and concerns have been raised elsewhere of the IESG acting as judge and jury on procedural matters that affect IESG standards actions. Probably the topic should be discussed on the IETF discussion list, but preferably with a change of subject from the current appeal discussion. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Reply-To (Was Re: [Re: regarding IETF lists using mailman: nodupes considered harmful])
Date: 2005-08-26 17:44 From: Peter Dambier [EMAIL PROTECTED] To: IETF General Discussion Mailing List ietf@ietf.org Reply to: [EMAIL PROTECTED] N.B.^^^ Iljitsch van Beijnum wrote: No, what needs to happen if we collectively decide we don't want the current behavior is that the mailinglist software sets a reply-to header, so when you hit reply or group reply your reply is sent with the list in the To: field and nothing else. This used to work well, not sure if modern clients handle this correctly, though. Try to reply to this message to see what happens. One important nit: Reply-To is an originator field (RFC 2822) and should never be forged by somebody or something (e.g. list expander) other than the originator. Mailing lists have the List-Post field (RFC 2369) available for mailing list use, e.g.: List-Post: mailto:ietf@ietf.org Great, it works! Except of course when some people (ahem!) set Reply-To to an individual mailbox, forcing respondents to use a reply-all function to reach the discussion list (with a copy to the specified mailbox) if the optional List-Post field is missing... It is unsurprising that Reply-To functions in that manner; it is an explicit purpose of the field dating back at least to RFC 724 (May 1977): 3) Reply-to: This field provides a general mechanism for indicating any mailbox(es) to which responses are to be sent. Three different uses for this feature can be distinguished. In the first case, the author(s) may not have regular machine-based mailboxes and therefore wish to indicate an alternate machine address. In the second case, an author may wish additional persons to be made aware of, or responsible for, responses; responders should send their replies to the Reply-to: mailbox(es). More interesting is a case such as text-message teleconferencing in which an automatic distribution facility is provided and a user submitting an entry for distribution only needs to send their message to the mailbox(es) indicated in the Reply- to: field. text-message teleconferencing is a quaint reference to mailing lists. Date: 2005-08-26 23:46 From: Joel M. Halpern [EMAIL PROTECTED] I really hate lists with reply-to pointing to the list. I know when I want to reply to the list, and when I want to reply individually to the sender. When reply-to points to the list, it is extremely difficult with most mailers to send a reply to the originator. Kmail, Evolution, and Sylpheed each have options for sending a response to the message author directly, and Pine prompts for a user decision. For others, selection from a list or copy-and-paste often suffice. I won't try to characterize most UAs, as I haven't examined all of them, but if a particular one lacks a feature, the most effective ways to remedy the problem are to contact the supplier or, failing a suitable enhancement, to switch to a UA that does provide the desired functionality. Certainly there are plenty of products available. As noted in RFC 724 and its successors, there are several reasons for use of the Reply-To field; clearly neither the field nor its uses are new. The lack of a facility for dealing with messages using the Reply-To field for its intended purpose is a serious defect in an MUA. Date: 2005-08-27 02:16 From: Frank Ellermann [EMAIL PROTECTED] My astonishment factor was worse than the small difficulty to copy and paste From when I know that I have to be careful. Reply-To is a standard field and ought to be visible when viewing the original message [1]. In any event, the To field of the response ought to be clearly visible. In either case, if not, see above re. effective ways to remedy UA problems. 1. Part of the problem is UAs which suppress message header fields, caused by the proliferation of noise fields in the message header (initially SMTP Mail-From, subsequently renamed Received, and now including a large number of others). There is a series of drafts describing a backwards-compatible extension to the Internet Message Format to rectify that problem. See draft-lilly-extensible-internet-message-format-p01-00 and related parts p02-p04. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Autoresponder lameness
The IETF discussion mailing list's recipients seem to be particularly lax about conforming to IETF mail specifications. If it weren't sad, it would be funny, as shown by the following real example and related commentary (some message header fields elided for brevity): - Return-Path: [EMAIL PROTECTED] [...] Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by mx05.mrf.mail.rcn.net with ESMTP; 28 Aug 2005 10:16:14 -0400 [...] Received: from zrchb007.us.nortel.com (zrchb007.us.nortel.com [47.103.121.51]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7SEGAs23776 for [EMAIL PROTECTED]; Sun, 28 Aug 2005 10:16:11 -0400 (EDT) Received: by zrchb007.us.nortel.com with Internet Mail Service (5.5.2653.19) id RLR2HA26; Sun, 28 Aug 2005 09:16:09 -0500 Message-ID: [EMAIL PROTECTED] From: David Monachello [EMAIL PROTECTED] To: Bruce Lilly [EMAIL PROTECTED] Subject: Out of Office AutoReply: Last Call: 'Tags for Identifying Languag es' to BCP Date: Sun, 28 Aug 2005 09:16:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain [...] Effective immediately, this e-mail account is no longer in service. You will only receive this notice once. As part of the Nortel Networks acquisition of PEC Solutions Inc., this e-mail address has been changed to: [EMAIL PROTECTED] Please update your contact information. To obtain the individual's new phone number please call Nortel PEC Solutions Front Reception at (703)679-4900. This e-mail has been auto forwarded. Subsequent e-mail messages will be forwarded for a limited transition period. Comments on this instance of a delivery notification message: 1. Delivery notifications should have the return-path (SMTP envelope sender) set to a null value to prevent loops. In this case, the return-path was set to what is presumably the specific non-functional mailbox which is the subject of the message text (although nowhere does the message say so explicitly)! Note that the message From field is also set inappropriately. 2. Delivery notifications should be sent to the original message return path. In this case, as I have never sent any message to the individual in question, the message must have resulted from delivery of an IETF discussion list message, which would have had [EMAIL PROTECTED] as the original message return path. 3. The most appropriate action for Nortel Networks would have been to have notified Mr. Monachello of the change and to have requested him to have revised the mailbox used for receipt of mailing list messages, in which case there would have been no need to send any sort of delivery notification message at all. Failing that, notification should have been sent to [EMAIL PROTECTED], where the notification of a change could be effectively handled; I can do nothing with the information about the change of mailbox for Mr. Monachello; the notice sent to me personally is annoying and causes me to hold Mr. Monachello, Nortel Networks, and Microsoft (purveyor of Internet Mail Service) in lower esteem than prior to receipt of the message. 4. None of the above is rocket science; it is clearly specified in RFC 3834, which has the unsurprising title Recommendations for Automatic Responses to Electronic Mail, and which itself distills long-standing practice regarding such responses as documented in the SMTP specifications and in such obscure documents as the Host Requirements standard (RFC 1123, a.k.a. STD 3). It's also common sense. The message has been dealt with as spam; future messages of a similar nature are likely to be automatically filtered (and automatically reported to Pyzor and SpamCop as spam). And this isn't an isolated instance; I've seen quite a few similar messages, as other contributors to the IETF discussion list no doubt have. Fellow IETFers: please make sure that any vacation-like automatic responders under your control or in use at your organizations comply with the Host Requirements, the SMTP specifications, and the recommendations in RFC 3834. And to those of you who are responsible for the non-conforming behavior of certain automatic responders, shame on you. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Is it necessary to go through Standards Track to Get to Historic? (WAS: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02)
On Sun, 28 Aug 2005, Bruce Lilly wrote: The Historic category of published RFCs can be used for documents which specify a protocol or technology which is known to be harmful to the Internet. However, RFC 2026 appears to have no provision for getting to Historic except via the Standards Track [...] What makes you say that? It sure isn't what I read from RFC 2026. It says this in Section 4.2.4: A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the Historic level. (Purists have suggested that the word should be Historical; however, at this point the use of Historic is historical.) Seems to me that the proviso is for any other reason considered to be obsolete could reasonably be construed to cover the initial publication of an obsolete specification. It's certainly true that the most common way to get to Historic is to start on the standards track and then get retired, but I see nothing in RFC 2026 that says (or even implies) that this is the only way. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02
John Glube wrote in mxcomp: I should have written: |The underlying benefit of e-mail authentication for senders |interested in e-mail delivery is to establish a framework that |supports certification and reputation services, both external |and internal to facilitate the delivery of ham, while rejecting |spam [1] That was not the main purpose of SPF. SHOULD check HELO was added in 2005, because it was always allowed and possible, and it makes sense for the reasons you have stated. But the main idea of SPF is to get rid of backscatter, numerous bogus bounces / challenges / other auto-responses to forged Return-Paths. With side effects, some hard, others desirable. Above all _save_ good bounces because SMTP without any bounces won't work. To save the good bounces and other auto responses it is essential to get rid of the bad backscatter a.s.a.p. How fast it's adopted by senders or receivers is less important - that smart spammers stay away from FAIL-protected addresses is the point. SPF is designed to offer an immediate benefit for participants, especially spoofed senders. receivers can use their sender policy records for what ever purpose they want, irrespective of the stipulated protocols is not acceptable. Of course, receivers could decide to block everybody with(out) sender policy, count characters in a sender policy, or check a Message-ID, etc. Their server, their rules. Nevertheless those interested to avoid backscatter will try to follow the rules as defined in the SPF RfC. Or they use a proper subset, e.g. without FAIL-chance I won't waste time, or let's only use PASS + white lists, or MAIL FROM stuff is tricky, forget it, but the HELO tests are nice. Other checks (PRA, Message-ID, policy length in characters) are NOT RECOMMENDED, because that's not what the publisher of a v=spf1 policy intended. And as William pointed out, it would be also FUBAR to try a HELO-test with a spf2.0/pra policy. A PRA-policy is not for HELO tests. Receivers are free to try it anyway, but they are far beyond anything specified in the senderid drafts if they do this. And of course this won't work, any FAIL they'd get would be a fantasy-FAIL, not a senderid-FAIL, let alone a SPF-HELO-FAIL. SID like SPF is a protocol, it works as designed, receivers are on their own if they break or twist it. One thing that is erroneously specified in SID (= _not_ working as designed) is to check PRA against v=spf1. That's the point of the appeal. No amount of weasel words can change this, it is a serious security bug and has to be fixed. it seems SPF folks supporting the appeal are not interested in pushing back on Microsoft as it relates to the IPR Why should we ? It's none of our business, that's something SID-implementors would discuss with MS. I'm confident that MS can handle all IPR questions about SID without any help from the SPF community. simply want to fully sever the relationship between spfv1 and spf2.0. That's not the case, it's okay to share the same DNS RR, it's okay to use v=spf1 as spf2.0/mfrom, it's okay to use the same result codes, the same error handling, an almost identical syntax, and the same processing limits. So why should they reinvent the wheel, build on the work of others. I've seen statements from Wayne where he offers to help with spf2.0. I'm sure that Meng would also help. I've offered op=pra as a way to get an spf2.0/mfrom,pra effect in a v=spf1 op=pra record for those who explicitly want it: http://purl.net/xyzzy/home/test/draft-spf-6-3-options-08.txt So far they didn't react and want any help - no big surprise, from a technical POV neither SPF nor SID are rocket science. In that case, I presume the SPF Community has no problem with these potential developments: I skip this, ex falso quodlibet. there is every possibility that those supporting technical purity within the SPF Community are in for a rude awakening The rude awakening when an SDO like the IETF intentionally allows conflicting standards (experiments) only to please MS would be far worse. Bye, Frank (please fup2 general list) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Autoresponder lameness
Bruce Lilly wrote: Delivery notifications should be sent to the original message return path. Yes, I've mentioned RfC 3834 in my first three complaints (some obscure script sending Alerts to the mailing list From, I'm not sure which list, mxcomp or IETF general or both). I also proposed to killfile me, or to discuss the problem - whatever it might be, I have no clue - with the list moderator / owner. The message has been dealt with as spam Same here. I could also bother the list owner / moderator, but it's a weekend, maybe my direct complaints have an effect. Fellow IETFers: please make sure that any vacation-like automatic responders under your control or in use at your organizations comply with [...] the recommendations in RFC 3834. Seconded. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reply-To
Bruce Lilly wrote: Part of the problem is UAs which suppress message header fields, caused by the proliferation of noise fields in the message header (initially SMTP Mail-From, subsequently renamed Received, and now including a large number of others). s/Received/Return-Path/ (or is this some pre-821 history ?) Ordinary users are most probably not often interested in the timespamp lines, and MUAs not showing them in their default configuration are fine. See draft-lilly-extensible-internet-message-format-p01-00 and related parts p02-p04. Sorry, so far I didn't have the time to read your drafts (but I have them in my public collection ;-) Priority one on my todo-list after USEFOR is now 2821bis - first thing I plan is some kind of ABNF-diff. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reply-To (Was Re: [Re: regarding IETF lists using mailman: nodupes considered harmful])
On 28-aug-2005, at 19:55, Bruce Lilly wrote: One important nit: Reply-To is an originator field (RFC 2822) and should never be forged by somebody or something (e.g. list expander) other than the originator. Well, to me, the mailing list re-originates the message, so I don't see the problem. (Why did you set a reply-to header, then?) Kmail, Evolution, and Sylpheed each have options for sending a response to the message author directly, and Pine prompts for a user decision. For others, selection from a list or copy-and-paste often suffice. The trouble is that the mail clients I'm familiar with (and that's not too many, somehow learning a new one always freaks me out) give the user the option to either reply to the sender (as in: address in the From: header) or do a group reply, where everyone else is put into the CC: header. What I would really like is reply to the list but that's not an option. Removing the sender in To: and moving the list from CC: to To: is too much work: there is considerable mousing or complex keyboard stuff involved. I know it sounds silly that a two- second task would be too much work, but then, apparently the much simpler task of simply removing any unnecessary text left at the bottom of the finished message (shift-apple-cursor down backspace in my case) is deemed too hard for more and more people, with the result that each reply contains all messages before it, if these lazy bandwidth-wasters are left to their own devices. the most effective ways to remedy the problem are to contact the supplier or Not effective at all. My mail client is broken in several ways since the last OS update several months ago, but so far, the bugs aren't even acknowledged, let alone fixed. So feature requests: forget it. failing a suitable enhancement, to switch to a UA that does provide the desired functionality. Is there a list of what functionality can be found where? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Tags for Identifying Languages' to BCP
Bruce Lilly wrote: While there is some mention of this issue in the document under discussion, its treatment and resolving the underlying issue in a manner that would minimize the problems are lacking. That's a last call, if you have better ideas than those in the draft speak up. Your Content-Script idea is good, but won't help e.g. in encoded words (2047+2231). We definitely tried to minimize especially this problem. This is a ready-for-Bruce's-review draft as far as I can judge this, but for obvious reasons only you can really judge it. ;-) Addressing the language range issue is not a WG work item and, unfortunately, the algorithm issue is scheduled to be a later work item than the registry issue. Only my personal view of course, but the matching draft offers a syntactical form for ranges, and the Suppress-Script in the registry provides for backwards compatibility where possible. it is essential that such negotiation issues be considered carefully before specifying the format of tags. Unfortunately, that has not been done IBTD, we considered the script issues. Anything else is as good or bad as it is with 3066 - some minor problems fixed of course, if ISO 3166-1 pulls another CS 3066bis will handle it better than 3066 (no potential worldwide retagging confusion). the WG product lacks the particular care expected of BCP documents (RFC 2026). IBTD as far as scripts are concerned. it appears that management of WG participant conduct has been rather lax IBTD, the WG Chairs and the responsible AD did a very good job. as it stands, the document cannot be evaluated for soundness of the tag syntax design in the absence of a specification that addresses negotiation issues (in a backwards-compatible manner with the existing negotiation mechanisms (viz. MIME Content- and Accept- fields and feature/filter negotiation). IBTD, see above. Your idea to split tag and registry syntax from all procedural aspects of tag registration is possible, but you get the same effect by ignore the procedural stuff in chapter 3 (= about 14 of the 60 pages in the draft). Revision to move the syntax specification to a separate document, as mentioned above, would permit evaluation of the registration procedures per se You can also read chapter 3 per se, the mentioned 14 pages plus 3.1 as introduction (5 pages, format of the registry). I'm not violently against splitting the document, but it's IMHO unnecessary. Bye, Frank (also posted on the LTRU list) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Is it necessary to go through Standards Track to Get to Historic?
Date: 2005-08-28 14:45 From: C. M. Heard [EMAIL PROTECTED] On Sun, 28 Aug 2005, Bruce Lilly wrote: The Historic category of published RFCs can be used for documents which specify a protocol or technology which is known to be harmful to the Internet. However, RFC 2026 appears to have no provision for getting to Historic except via the Standards Track [...] What makes you say that? It sure isn't what I read from RFC 2026. It says this in Section 4.2.4: A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the Historic level. (Purists have suggested that the word should be Historical; however, at this point the use of Historic is historical.) That defines the sort of documents that fit into the category, but doesn't specify how they get there. It is analogous to 4.2.1 (Experimental) and 4.2.2 (Informational). Seems to me that the proviso is for any other reason considered to be obsolete could reasonably be construed to cover the initial publication of an obsolete specification. It's certainly true that the most common way to get to Historic is to start on the standards track and then get retired, but I see nothing in RFC 2026 that says (or even implies) that this is the only way. The only specific procedures for getting to Historic in 2026 are in sections 6.2 and 6.3 and involve getting to Historic from the Standards Track. Note that section 4.2.3 gives procedures for Informational and Experimental RFCs, but that the only specific procedures for Historic are in sections 6.2 and 6.3. Now I personally wouldn't mind a revision to 2026 where the same procedures for Informational and Experimental were also applicable to Historic (while retaining the mechanisms for migrating from the Standards Track to Historic). For that matter, I'd also prefer to see the procedure modified to include IESG review including IETF Last Call for individual submissions (2026 specifies going directly to the RFC Editor). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reply-To
Date: 2005-08-28 15:28 From: Frank Ellermann [EMAIL PROTECTED] Bruce Lilly wrote: Part of the problem is UAs which suppress message header fields, caused by the proliferation of noise fields in the message header (initially SMTP Mail-From, subsequently renamed Received, and now including a large number of others). s/Received/Return-Path/ (or is this some pre-821 history ?) RFC 821's predecessor, RFC 788: The time stamp line and the return path line are formally defined as follows: return-path-line ::= Return-Path: SPreverse-pathCRLF time-stamp-line ::= Mail-From: SP stamp CRLF stamp ::= [ptcl] from-host this-host daytime ... Ordinary users are most probably not often interested in the timespamp lines, and MUAs not showing them in their default configuration are fine. Interesting typo; maybe the lines should in fact be referred to as timespam. The problem with UAs suppressing header fields is that some of them suppress important fields which communicate information from the message originator to recipients (e.g. Reply-To). The SMTP precedent of modification of the message (header) content after leaving the originator has directly led to other modifications (List- fields and a plethora of X- fields) which in turn have led to the practice of suppressing display of fields. It's a tough problem for a UA author, as there is no way to automatically determine whether some new message header field is a new originator field (which should not be suppressed) or some transport noise (which should be suppressed). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reply-To
Date: 2005-08-28 15:42 From: Iljitsch van Beijnum [EMAIL PROTECTED] On 28-aug-2005, at 19:55, Bruce Lilly wrote: One important nit: Reply-To is an originator field (RFC 2822) and should never be forged by somebody or something (e.g. list expander) other than the originator. Well, to me, the mailing list re-originates the message, so I don't see the problem. So you think it's OK for a list expander to modify Sender and From Fields (the other Originator fields in 2822 sect. 3.6.2)? [some list expanders do in fact modify Sender, causing problems] (Why did you set a reply-to header, then?) To suggest where responses should be sent; that is the purpose of the field. There is a difference between the originator setting an Originator field and some other entity modifying an Originator field. Unless Originator fields are set exclusively by the originator, it is not possible for a recipient to determine who set the field. Kmail, Evolution, and Sylpheed each have options for sending a response to the message author directly, and Pine prompts for a user decision. For others, selection from a list or copy-and-paste often suffice. The trouble is that the mail clients I'm familiar with (and that's not too many, somehow learning a new one always freaks me out) give the user the option to either reply to the sender (as in: address in the From: header) That would be the author(s); the sender would be indicated by the Sender field. or do a group reply, where everyone else is put into the CC: header. What I would really like is reply to the list but that's not an option. It is in fact an option in Kmail, in Evolution, and in Sylpheed (although the implementations do not necessarily do the same thing). the most effective ways to remedy the problem are to contact the supplier or Not effective at all. My mail client is broken in several ways since the last OS update several months ago, but so far, the bugs aren't even acknowledged, let alone fixed. So feature requests: forget it. Different suppliers of course provide different levels of response... failing a suitable enhancement, to switch to a UA that does provide the desired functionality. Is there a list of what functionality can be found where? I wouldn't be surprised, but I don't know of any off-hand (and such things would rapidly become out-of-date). If you have a suitable mail environment, the easiest thing is to experiment (a suitable environment is one where one can easily switch user agents, e.g. where the message store is an IMAP repository). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: language root file size
JFC (Jefsey) Morfin jefsey at jefsey dot com wrote: I started documenting some of the problems resulting from the expected size of the language tag registry and the capacity of the langtag solution to fulfill the WG-ltru Charter. Here are two inputs from the author of the Draft above on the WG-ltru list, Doug Ewell: - I've already built a hypothetical RFC 3066ter registry. The changes alone add up to 35,700 lines, or more than 740 pages in RFC format. It might reopen the question of whether an I-D is the best vehicle for delivering this amount of information to IANA. Some of you who have not had the joy of witnessing this sort of gross misrepresentation on LTRU over the past eight months might be a bit confused. At no time did I ever say, or imply, or MEAN, that the eventual size of the registry would be a problem in and of itself, nor that the solution developed by the LTRU WG would not fulfill the charter. What I said, as anyone can see from reading the quote above, is that a 740-page I-D might be unwieldy enough that the IETF might consider a different procedural mechanism for delivering the information to IANA. - I still have significant concerns about the assumption that ISO 639-6 will be, or should be, automatically integrated into a language tagging scheme. [snip] Meanwhile, the claim that there are over 20,000 languages to be tagged is being used as an argument against the current RFC 3066bis effort and the plan to support 7,600 languages in RFC 3066ter. Since the charter neither refers nor alludes to ISO 639-6, there is no conflict with the charter if WG members disagree in regard to the *eventual* expansion of the scope of language tags to involve ISO 639-6. The argument against the RFC 3066bis effort on the basis of the asserted existence of 20,000 languages is attributable to M. Morfin alone. He is not being truthful in saying that he does not oppose the draft; he has spent the entire lifetime of the LTRU WG, and before, shouting his opposition from the rooftops. I fully share the concerns of Doug Ewell. M. Morfin does not share any concerns with me, except to the extent he can twist my words to mean something I do not intend. I hereby disassociate myself with any statements made by M. Morfin concerning the drafts produced by the LTRU WG. I hope that is clear enough for IETF members. 2. the documented upgrade enlarge the size from 80 K (11.5 K zipped) to 650 K (100 K zipped). This information, updates and additions MUST be available to each of the on-line application of the devices of billions of users. The Draft does not explain how. The WG decided this was an IANA implementation issue, and out of scope. Clearly, if some consider it wrong to specify both a registry format and a registration procedure within the same draft, it would be that much worse to dictate to IANA how it should manage its resources. 2. One of the author has _legitimate_ concerns about the capacity of the proposition and the reasonability of the Charter expectation to support the ISO 639-6 evolution of the underlying ISO standards. Any talk within the LTRU WG regarding ISO 639-6 is just that: talk. There is no charter requirement to support ISO 639-6. (There *is* a charter requirement to begin paving the way for support of ISO 639-3, and we have addressed that requirement within the limitation that ISO 639-3 is still not an approved standard.) But he is wrong is in assuming that I use this as an argument against the current RFC 3066bis effort. To the contrary, I use it for a an argument to support the proposed Draft as default solution and support extensions and practical information distribution through other adapted solutions introduced by a singleton. I invite any interested IETF member to peruse the WG archives, and judge for himself whether M. Morfin supports the draft or not. Since there are no detectable RFC 3683 or 3934 constraints on M. Morfin's right to post anything he likes, I expect the usual scathing personal attack in response. (Don't bother sending it to me personally; I do have a Blocked Senders list.) -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Is it necessary to go through Standards Track to Get to Historic?
On Sun, 28 Aug 2005, Bruce Lilly wrote: The only specific procedures for getting to Historic in 2026 are in sections 6.2 and 6.3 and involve getting to Historic from the Standards Track. Note that section 4.2.3 gives procedures for Informational and Experimental RFCs, but that the only specific procedures for Historic are in sections 6.2 and 6.3. RFC 2026 sets the rules for Internet standardization, i.e., it is authoritative with respect to the handling of standards or BCPs. So it's fair to conclude that the procedures in sections 6.2 and 6.3 are the only way for a standards-track document to get to Historic. However, RFC 2026 does not set the rules for non-standards track documents, as it explicitly says in Section 2.1. It is therefore incorrect to conclude from a lack of explicit mention of a mechanism in RFC 2026 that it is impermissible to publish an obsolete specification Historic without going through the standards track. There is a precedent, by the way: RFC 2341. Note that it postdates RFC 2026. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Tags for Identifying Languages' to BCP
Dear Bruce, I will try to quickly comment/respond/suggest on some of your well made points. At 16:15 28/08/2005, Bruce Lilly wrote: Date: 2005-08-25 20:55 From: JFC (Jefsey) Morfin [EMAIL PROTECTED] the privacy problem is the what you read, who you are intelligence leak. That is to some extent true of any negotiation mechanism and negotiated value. True. The problem are: - the unecessary accumulation of orthogonal information - the easily identified characteristic format: an enormous difference between xx-xx-xxx-xx (Draft) and (ISO 639-6) - the lack of alternative (are we sure there are no other architectural way to address the same need without information leak) - the lack of encryption - the spam aspect: I am imposed to receive the langtag. Today langtags are not yet much used (say the W3C people in the WG-ltru) when compared with what they should in XML, HTML, etc. XML, HTML, etc. are not IETF protocols and should not be the main consideration in IETF work on IETF documents, They are specifically quoted by the Charter. Also is CLDR a private proposition to unify locale file which has interest but also competition. especially as language tags are heavily used by IETF protocols, notably MIME (RFCs 2045, 2047, 2231, 3282) and widely-deployed core IETF application protocols which use MIME (e.g. the Internet Message Format and its applications (email, news, voice messaging, EDI, etc.) and HTTP and applications using HTTP as a substrate. RFC 2231 is among the reference quoted. I more interested in RD. My concern is that OPES have been disregarded. This is all what this proposition is about. This proposition is to give _one_shot_ in a _standardised_ way the language, the script and the country. This was discussed during Last Call of the previous non-IETF (individual submission) attempt. IIRC David Singer brought up several examples of other pieces of information (e.g. legal/copyright variations) that could also be negotiated and which might affect the presentation of content (or choice among alternative content). Lumping all of these separate items into one tag is a poor design as it impedes negotiation and tends toward lengthy tags which are incompatible with fixed-length mechanisms such as MIME encoded-words. While there is some mention of this issue in the document under discussion, its treatment and resolving the underlying issue in a manner that would minimize the problems are lacking. The work we carried on language in a common reference center (where are stored the common parameter of a relation) shown us that must be included in negociation two classes of additional information. The parameters in the community (we call referent: i.e. dictionary, etc) and the context of the exchange (style, personal meanings, circumstances, etc.). These elements are necessary for OPES call-out servers supervising a relation. These elements are by default used by ... Word (language, script, country, dictionary, style). The Draft proposes a system which permits to evaluate the locale the computer should support for end to end interoperability purposes. It does not necessarily permit to establish, maintain and serve a brain to brain interintellibility. Let's separate three issues: 1. privacy 2. tagging 3. negotiation The privacy issue exists whenever any information is conveyed; the user needs to balance privacy concerns with facilitation of communication. Mechanisms such as TLS can be used to limit the visibility of the information to the end points of communication; ultimately it boils down to a matter of trust in the end-point partner in the communication exchange. I believe that the issue is dealt with adequately in the security considerations section of the document under discussion (some mention of transport-level protection of privacy would be welcome). Not really: see above. The concept is an help to privacy violation: - more secure alternatives should be investigated and proposed - the danger is not worth the result, necessary information is missing. Tagging identifies characteristics of a particular piece of content. For that purpose alone, it makes little difference (other than regarding the aforementioned compatibility issues with existing IETF mechanisms) whether the characteristics are lumped or separate. There are existing IETF mechanisms which permit handling of either lumped or individual characteristics (e.g. the extensible header field mechanism of RFC 2045 and the feature/filter mechanism of RFC 2533/2738/2912). Tagging per se identifies characteristics of content. While that may be used to infer something about the content provider, such inferences may be unreliable, particularly for providers that support a wide variety of characteristics for the content in question. This confusion will be an increasing problem. More and more the architext we use (the data from which we infer the text we read) become intelligent and
Re: Last Call: 'Tags for Identifying Languages' to BCP
At 16:42 28/08/2005, Bruce Lilly wrote: Date: 2005-08-25 20:55 From: JFC (Jefsey) Morfin [EMAIL PROTECTED] please document how do you do, while respecting the hybrid format of the proposed ABNF where information is not indentified by fixed position, but also relative position and size, with - as sole separator. And they want to keep labels between - 8 characters long. Tell me how you support IDNs. Let suppose that I have lang-tags.org: as a scheme. or xn--abcdef.com:. Tell me how you support them It's unclear what you're trying to get at here. A URI scheme is a protocol element (an assigned number) registered by IANA, not a piece of text (see RFCs 1958 and 2277). A proposition I received from the WG-ltru was to slice URI tags into 8 aphanum labels, etc. Among many problems URI tags accept domain names, mail names and IP addresses as registered identifiers. The main problem with the ABNF is therefore the use of - as a separator since - is a legitimate character in domain name. The support of IRI tags is impossible. Our work is on CRC (common reference centers). offering such references. URI tags are the correct solution (with some restrictions we will probably document once the RFC is published) As such, it has no need of an indication of language, for it has no language; it is a language- independent protocol element. Confusing protocol element issues with language will only muddy the water; try to stay focused on real problems. For that matter, DNS labels are public names (i.e. protocol elements, again see RFC 1958 (sect. 4.3, noting that text there has a different meaning than in RFC 2277)) and as such there should not have been any reason to overload the semantics and baggage of internationalized text (in the RFC 2277 sense). Now, having made the decision to nevertheless do so, you might well point out that per RFC 2277, there ought to be a means of indicating language in IDNs. However, that is primarily an issue with the IDN specification(s), not with the document under discussion (except to the extent that the document under discussion extends the likely length of tags in a way that is likely to conflict with the DNS label length and domain name length limits, *if* there were in fact provision in IDN for the use of language tags. Fully correct. The response is with the approved pending URI Tags RFC. IRT IDN, as a multilingualiser I disapprove IDNA. But whatever the final solution the MLDN charsets may use a langtag like solution. Hence the interest. Another interest is that currently the IANA uses RFC 3066 language tags to identify the IDN tables. What is IMHO an error. You might also point out that as IDNs use utf-8 exclusively as a charset, and as script is easily inferred from the Unicode code points corresponding to utf-8, that the length-increasing provision for conflating script with language would be unnecessary and redundant *if* IDNs had provision for language tags. But IDNs have no such provision at this time. Correct. The MLDN problem is IMHO a different issue. However I say: 1. a langtag may be associated to a locale (this is in the WG-ltru Charter [Unicode CLDR project and our own ISO 11179 related solution]) 2. we think there should be DNS locale for some important sites and services 3. DNS locale could also be the proper place to distribute MLDN virtual zones charsets (several concepts to discuss, specify and deploy). jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
STD (was: Last Call: 'Tags for Identifying Languages'toBCP)
An exchange on WG-ltru documents (I do not say support: the reader will judge) the positions I support. It involves: - Peter Constable: one of the initiator of the project and author of ISO 639-3 which lists 7500 languages and is used in building langtags - Doug Ewel: author of the Draft concerning the initial content of the registry - Debbie Garside: the author of ISO 639-6 At 22:20 28/08/2005, Peter Constable wrote: [I'll preface this reply by saying that we don't want to spend too much time discussing issues that are not of immediate concern while we've got the matching draft and IETF last call on the registry drafts to deal with. So, I won't pursue this thread much longer.] The proposed Draft is based upon ISO 639-1,2,3 lists of language names. ISO 639-6 is a list of language use names and IDs. The proposed langtag is an arbitrary limited compound of three information: language name, script and country. A language identification MAY call for far more elements, and deliver much more information. However these three basic elements are necessary to sell lingually related products (contract, ads, documentation, bills) and identify the current status of the art locales (CLDR project). The alternative seems to be: - GO for an e-commercial only multilingual internet, for ever. - NO we do not want the Multilingual Internet to be only commercial. The decision is NOW. And we understand Peter and the authors wants to win now, because they have real needs to address now. But I do not think there is a need for anyone to win. There is a third response. - GO for an e-commercial multilingual internet support now, as default/immediate solution - YES to a generalised Multilingual Internet hooked to the RFC 3066 Draft how poor it is, using its reserved ABNF hooks. This means that: - fr-Latn-fr is the default tag based upon ISO 639-1/2/3 - x-fran is a private use tag based upon ISO 639-6 - 0-jefsey.com:franver is my vision of the French at the Palace of Versailles. Documented by an ISO 11179 conformant system (see below) From:Doug Ewell I'm a bit surprised that a work characterized as a work-in-progress and not yet ready for public review is nevertheless deemed ready to be considered as a draft international standard. Debbie at no point said that it was -- and it is not. It will be December at the earliest that it can be registered as a CD, and it must successfully complete a three-month ballot as CD before it can be registered as a Draft International Standard. So last spring of 2006 at the earliest. This means that this debate is only to lock a _final_ ABNF via an accepted RFC and a loaded operationalIANA registry _before_ a simpler solution is available three months from now In other words, in the system as proposed, you could use either the alpha-4 representation or the unique DI to find the closest 639-1,-2,-3 or -5 tags should you so wish. But in language tags, either one value needs to be canonical -- sorry, preferred -- over the others, or else the duplicative values should not be added at all. Your statement doesn't contradict anything that Debbie has said, provided the context is ISO 639-6 alone. If we were to talk about incorporation of ISO 639-6 into a revision of RFC 3066, however, then duplication would become an issue for consideration. This is the WG-ltru Charter that all the ISO codes be included. As a user I am not much interested in mixing four formats only to please Peter Constable and/or Debbie Garside. All the more than the issue is the addition of the script information to document ... oral expression and they miss computer(ised?) languages (definition?) and all this is through computers. For clarification of Debbie's statement, in the model of ISO 11179, we have metadata elements that consist of a data element concept, such as 'English', and a representation for that, such as en or eng (these would be distinct representations belonging to different value domains). Within an metadata registry, a registry item corresponding to 'English' can have a Data Identifier (DI), which is a unique identifier *within the registry* for that administered item; in this example, that DI could be any number of strings, though English would be among the better choices. Nice to see that ISO 11179 is accepted now. Peter Constable and the WG-ltru have opposed the reference to ISO 11179 model. This model permits to conceptualise languages and to include in their description an unlimited number of additional elements. Roughly it means that ISO 639-3 is a table of codes (names) related to non documented languages. While ISO 639-6 wants to be a root to a base of objects describing languages. The Draft proposes a very limited version of that base with three columns only. This is enough in many cases. But not in an increasing number of cases. Hence the possibility to use the Draft as a default. Since the three elements of the Draft's langtag are
Re: Last Call: 'Tags for Identifying Languages' to BCP
From: Bruce Lilly [EMAIL PROTECTED] It's unclear what you're trying to get at here. A URI scheme is a protocol element (an assigned number) registered by IANA, not a piece of text (see RFCs 1958 and 2277). As such, it has no need of an indication of language, for it has no language; it is a language- independent protocol element. This point was made in response to Mr. Morfin on more than one occasion within the LTRU WG. He appears to be unwilling to accept it, however. ought to be a means of indicating language in IDNs. However, that is primarily an issue with the IDN specification(s), not with the document under discussion (except to the extent that the document under discussion extends the likely length of tags In comparison to RFC 3066, the draft does not extend the likely length of tags. The likely length of tags is precisely the same as before; the main difference is that this draft imposes significant structural constraints on tags. Peter Constable ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Dynamic salting in encryption algorithms for peer to peer communication
Dear Atul, I have the same thought regarding dynamic techniques, in this case the encryption. If you use a well known mathemtical formula, I think passive attackers may still have a chance to challenge it. What if the encryption algorithm is made dynamic? It means that each peer can update and upgrade peer's algorithm whenever required. Regards, Benny -- Benny B. Nasution Peninsula School of Information Technology Information Technology Faculty Monash University A U S T R A L I A +61 401 230 818 +61 397 696 078 email: [EMAIL PROTECTED] - Original Message - From: Atul Sabharwal [EMAIL PROTECTED] Date: Sunday, August 28, 2005 7:28 pm Subject: Dynamic salting in encryption algorithms for peer to peer communication ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf Title: Message Generally, I have seen that people use PKI or static salts for encrypting data e.g. password. In case of peer to peer communication, would it be useful to use dynamic salts derived from known mathematical series e.g. Fibonacci series, Ramanajum number series. The first salt need not be item(1) of the list but a random item(N) out of a circular series of M items. This could be useful for VPN client/server from same vendor. Web site /Java Applet from a company etc. IsSSL still more secure than dynamic salting for man in the middle attack ? -- Atul ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ltru] Re: Last Call: language root file size
I am sorry to impose that kind of response - and a large number of mails. But this shows the problem to protect an open RD capacity against a chapel, which as some good points. And a non-profit RD against people sharing in a commercial competing consortium. At 02:05 29/08/2005, Doug Ewell wrote: JFC (Jefsey) Morfin jefsey at jefsey dot com wrote: I started documenting some of the problems resulting from the expected size of the language tag registry and the capacity of the langtag solution to fulfill the WG-ltru Charter. Here are two inputs from the author of the Draft above on the WG-ltru list, Doug Ewell: - I've already built a hypothetical RFC 3066ter registry. The changes alone add up to 35,700 lines, or more than 740 pages in RFC format. It might reopen the question of whether an I-D is the best vehicle for delivering this amount of information to IANA. Some of you who have not had the joy of witnessing this sort of gross misrepresentation on LTRU over the past eight months might be a bit confused. At no time did I ever say, or imply, or MEAN, that the eventual size of the registry would be a problem in and of itself, nor that the solution developed by the LTRU WG would not fulfill the charter. What I said, as anyone can see from reading the quote above, is that a 740-page I-D might be unwieldy enough that the IETF might consider a different procedural mechanism for delivering the information to IANA. Correct. I do not see the need of all the innuendo above to repeat what I quoted. - I still have significant concerns about the assumption that ISO 639-6 will be, or should be, automatically integrated into a language tagging scheme. [snip] Meanwhile, the claim that there are over 20,000 languages to be tagged is being used as an argument against the current RFC 3066bis effort and the plan to support 7,600 languages in RFC 3066ter. Since the charter neither refers nor alludes to ISO 639-6, there is no conflict with the charter if WG members disagree in regard to the *eventual* expansion of the scope of language tags to involve ISO 639-6. This repeated allusion to the Charter neither refering nor alluding to ISO 639-6 is to be compared with the text of the Charter (http://ietf.org/html.charters/ltru-charter.html) which says It is also expected to provide mechanisms to support the evolution of the underlying ISO standards, in particular ISO 639-3. This kind of problem may be related to the refusal of the WG to start from/analyse the Charter requirments? The argument against the RFC 3066bis effort on the basis of the asserted existence of 20,000 languages is attributable to M. Morfin alone. He is not being truthful in saying that he does not oppose the draft; he has spent the entire lifetime of the LTRU WG, and before, shouting his opposition from the rooftops. I fully share the concerns of Doug Ewell. M. Morfin does not share any concerns with me, except to the extent he can twist my words to mean something I do not intend. I do not know if I share concerns with Doug. I do share the concerns of Doug. I hereby disassociate myself with any statements made by M. Morfin concerning the drafts produced by the LTRU WG. I hope that is clear enough for IETF members. Since I said I supported his Draft 2. the documented upgrade enlarge the size from 80 K (11.5 K zipped) to 650 K (100 K zipped). This information, updates and additions MUST be available to each of the on-line application of the devices of billions of users. The Draft does not explain how. The WG decided this was an IANA implementation issue, and out of scope. Correct. This is exactly what I say. Clearly, if some consider it wrong to specify both a registry format and a registration procedure within the same draft, it would be that much worse to dictate to IANA how it should manage its resources. This is an interesting idea: because I disagree that a general registration procedure is documented in the same document as a specific format (but I propose to address the point in considering it as the default format) ... I would support the idea to pass to others what one does not know to address. I note that this has been done with much success in the IDNA case. 2. One of the author has _legitimate_ concerns about the capacity of the proposition and the reasonability of the Charter expectation to support the ISO 639-6 evolution of the underlying ISO standards. Any talk within the LTRU WG regarding ISO 639-6 is just that: talk. Doug said in another mail I just think the two figures (7,600 and 20,000) could be seen as representing a fundamental disagreement. This is a legitimate concern at a time a LC is to engage the whole IETF in a direction where you think this is unclear. I would not qualify that of ust talk. This is something loyalty calls you to say, even if it is to explain why there is no fundamental disagreement. There is no charter requirement to support
Re: Last Call: 'Tags for Identifying Languages' to BCP
At 02:50 29/08/2005, Peter Constable wrote: From: Bruce Lilly [EMAIL PROTECTED] It's unclear what you're trying to get at here. A URI scheme is a protocol element (an assigned number) registered by IANA, not a piece of text (see RFCs 1958 and 2277). As such, it has no need of an indication of language, for it has no language; it is a language- independent protocol element. This point was made in response to Mr. Morfin on more than one occasion within the LTRU WG. He appears to be unwilling to accept it, however. Peter we all know you are worth better than that! you just show that you ignore what URI Tags are. This is embarrassing for you since your whole problem is the conflict of your proposition with this accepted RFC ought to be a means of indicating language in IDNs. However, that is primarily an issue with the IDN specification(s), not with the document under discussion (except to the extent that the document under discussion extends the likely length of tags In comparison to RFC 3066, the draft does not extend the likely length of tags. There is a confusion between two lengths. The length of the tag and the length of the subtags. The whole issue is that Peter's colleagues want to consider private and specialised tags as subtags, and impose them the size of a subtag instead of the size of a tag. This is where is the exclusion. This trick cannot stay for long: but if they get it accepted for now, this gives them time to establish their positions. This means that the legitimate URI tag: tags:x-tags.org:constable.english.x-tag.org must be accommodated into the format x----etc. instead of 0-x-tags.org:constable.english.x-tag.org This can only lead to a confusing deprecation of the RFC 3066bis which will be replaced by a generalised IRI-tags solution. The solution I propose consists only in accepting that what the Draft would call specialised subtags have a size limited to the tag length - 2, and an URI-tag charset. NB. Since x- was used in RFC 3066 and it has been pointed to me that a specific privateuse (in a VPN for example) could be needed, we selected 0- for an open format. Actually we suggest 1- for an encrypted format. No work has been yet carried on this. The likely length of tags is precisely the same as before; the main difference is that this draft imposes significant structural constraints on tags. Absolutely. This is the area of contention. Peter takes a loosely applied chancy non-exclusive proposition, to make it the significantly constrained exclusive rule of the Internet instead of correcting it and following the ISO innovation (ISO 639-6 and ISO 11179) as directed by the Charter. This permits him to exclude competitive propositions following or preceding that innovation. With the trick above: length and character wise a private tag is a subtag. and the lack of explanation of how billions of machines will know about the daily updated version of his 600 K file, without anyone paying for it, but me and the like. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: STD (was: Last Call: 'Tags for Identifying Languages'toBCP)
From: JFC (Jefsey) Morfin [mailto:[EMAIL PROTECTED] An exchange on WG-ltru documents... In this post from Mr. Morfin, it is difficult (at least for me) to ascertain his point other than in relation to certain specifics: The proposed langtag is an arbitrary limited compound of three information: language name, script and country. A language identification MAY call for far more elements, and deliver much more information. Mr. Morfin has often suggested to the LTRU WG that language tags should be able to provide greater information than is allowed by the draft. He has never provided any specific proposal except a request to permit certain private-use tags, which I will return to below. The consensus of the remainder of the LTRU WG is that the draft supports all relevant distinctions needed to describe the linguistic and written-form attributes of content as may be needed for all purposes, commercial and otherwise. This means that: - fr-Latn-fr is the default tag based upon ISO 639-1/2/3 - x-fran is a private use tag based upon ISO 639-6 - 0-jefsey.com:franver is my vision of the French at the Palace of Versailles. Documented by an ISO 11179 conformant system (see below) Two comments: First, Mr. Morfin suggested within the LTRU WG that the syntax for language tags should be loosened to permit additional characters, such as . and :. The remainder of the WG was in consensus that this was unacceptable due to backward incompatibility with processes designed to conform to RFC 3066. Secondly, Mr. Morfin has repeatedly made mention of ISO 11179, a series of ISO standards on metadata and metadata registries, indicating his view that language tags used on the Internet should be maintained in a registry conformant with ISO 11179, and therefore that the draft should make reference to those standards. He has also, on several occasions such as his comments above, cited ISO 11179 in relation to his views in a manner that appears to be intended to suggest that his views are superior to the draft because he has cited that series of standards while the draft does not. A reality check is in need here: - While Mr. Morfin cites ISO 11179, he has never made statements that clearly indicate that he actually understands those standards. - While Mr. Morfin refers to an ISO 11179 conformant system, none of the ISO 11179 series of standards contains any statement of conformance requirements. Thus, no such notion of ISO 11179 conformant is defined anywhere. All that can be said is that a system of metadata elements is maintained and administered using a certain amount of the conceptual model, practice and administrative infrastructure specified in the ISO 11179 standards. The draft uses some measure of these, though it does not make normative reference to ISO 11179. In terms of ISO 11179 notions, each entry in the proposed registry includes the two essential components of a metadata element: a representation, and a data element concept. Each item in the registry indicates (i) the representation used in language tags, (ii) a designator that indicates the value meaning and that can also serve as the data identifier, (iii) the object class (its type), (iv) the administrative status (limited to deprecated or not deprecated), as well as other properties. Thus, while it cannot formally be said that the draft conforms to ISO 11179 (since no terms of conformance are defined), I think it *can* reasonably be said that the draft creates a registry and system of metadata elements that is consistent with the model presented in ISO 11179. - The primary reason that the LTRU WG chose not to reference ISO 11179 in this draft had nothing to do with whether the WG considered ISO 11179 appropriate or valuable in general. Rather, it was that it was not deemed that reference to ISO 11179 would add significant value in the context of an IETF language subtag registry. Taken together, the ISO 11179 standards are long and complex, and have not to our knowledge been referenced in any other IETF metadata registry -- and certainly not in relation to RFC 1766 or RFC 3066, which specifications accomplish their purposes in spite of that absence of reference. Thus, when I see Mr. Morfin citing ISO 11179 in the course of arguing for some view that he holds, I consider that citation to have added nothing of significance in support of his view. This means that this debate is only to lock a _final_ ABNF via an accepted RFC and a loaded operationalIANA registry _before_ a simpler solution [ISO 639-6] is available three months from now This statement makes several assumptions of uncertain validity, not the least of which is that use of alpha-4 symbols from ISO 639-6 for IETF language tags would constitute a simpler solution. Given the widespread existing use of RFC 3066 tags, use of ISO 639-6 would have to go alongside use of multi-part tags of the
RE: Last Call: 'Tags for Identifying Languages' to BCP
From: JFC (Jefsey) Morfin [mailto:[EMAIL PROTECTED] This means that the legitimate URI tag: tags:x-tags.org:constable.english.x-tag.org must be accommodated into the format x----etc. instead of 0-x-tags.org:constable.english.x-tag.org As I mentioned in another message, Mr. Morfin submitted a request to the WG that the syntax in the draft be loosened to permit tags of the form indicated, and that the consensus of everyone else in the WG was to reject that request on the basis that (i) it would result in backward incompatibility with existing processes designed to conform to RFC 3066, and (ii) it was possible to create a scheme for semantically equivalent tags without breaking compatibility with RFC 3066. Peter takes a loosely applied chancy non-exclusive proposition, to make it the significantly constrained exclusive rule of the Internet instead of correcting it and following the ISO innovation (ISO 639-6 and ISO 11179) as directed by the Charter. This permits him to exclude competitive propositions following or preceding that innovation. The LTRU charter makes no reference whatsoever to ISO 639-6 or to ISO 11179. As I have explained elsewhere, Mr. Morfin's suggestion that the draft is incompatible with ISO 11179 while his alternative would be conformant is far from valid. Finally, I have not excluded competing propositions; I was one voice among many that rejected a request to permit . and : in the syntax, and to my recollection no other concrete proposal wrt syntax, let alone an overall system of metadata elements, was submitted by Mr. Morfin to the WG. With the trick above: length and character wise a private tag is a subtag. and the lack of explanation of how billions of machines will know about the daily updated version of his 600 K file, without anyone paying for it, but me and the like. It is completely unclear on what basis Mr. Morfin is suggestion that billions of machines will need to update my (?? I did not create it!) 600K file on a daily basis. There is no indication or likelihood that the language subtag registry proposed by this draft will change with a frequency approaching anything close to daily. Indeed, it is entirely likely that it will change rather less frequently than the RFC 3066 registry was likely to change. Peter Constable ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt
--On 28. august 2005 01:22 -0700 SM [EMAIL PROTECTED] wrote: The reasons for moving RFC 1032 from status UNKNOWN to status HISTORIC are light. Such a move would have a negative impact on active usage as RFC 3912 does not document the contact point for problems concerning a domain. Three thousand RFCs ago, RFCs were used for many things. I recommend readeing some other status UNKNOWN perspectives, such as RFC 1003 (Issues in defining an equations representation standard) or RFC 1019 (Report of the Workshop on Environments for Computational Mathematics). This particular RFC was (I think; people around at the time will correct me) brought out by SRI-NIC to make it easy for the early Internet users to get hold of its instructions; the IETF never had an opinion on it. The IETF *is not in the business of* document the contact point for problems concerning a domain. That duty is left to registry operators, who have a whole apparatus (ICANN) for making it possible to figure out how to do that. And they can ask to have such specs published as RFCs if they want to - it's been done before; examples include RFC 1875 (UNINETT PCA Policy Statements). But ICANN hasn't done that, so no policy related to any *current* domain administrator is on the record. The only possible reason I can see for doing anything to the status of RFC 1032 is becaue the existence of the RFC is (wrongly) abused to try to force people into changing their behaviour with the argument The IETF says so. Those people should stop taking the name of the IETF in vain. Status UNKNOWN seems like a fine status to keep, in my opinion. Status INFORMATIONAL would have been more likely if anyone had bothered to reclassify the status UNKNOWN documents back in 1989 or therabouts, when those stop appearing. But like today, the people managing the publication series seem to have found better use for their time back then. Harald pgpSlDxQ5Cn3T.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Tags for Identifying Languages' to BCP
From: JFC (Jefsey) Morfin [EMAIL PROTECTED] XML, HTML, etc. are not IETF protocols and should not be the main consideration in IETF work on IETF documents, They are specifically quoted by the Charter. Also is CLDR... These are cited in the charter only as examples in a statement to the effect that the RFC 3066 standard for language tags has been widely adopted in various protocols and text formats... It is to note that ISO 639-4 work is about discussing guidelines in that area. This work is under way and was not considered. Mr. Morfin appears to me to have no more than a very vague sense of the scope of ISO 639-4. Peter Constable ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Dynamic salting in encryption algorithms for peer to peer communication
In message [EMAIL PROTECTED], Benyamin Nasution writes: I have the same thought regarding dynamic techniques, in this case the encryption. If you use a well known mathemtical formula, I think passive attackers may still have a chance to challenge it. What if the encryption algorithm is made dynamic? It means that each peer can update and upgrade peer's algorithm whenever required. (a) this is off-topic for the IETF mailing list (b) cryptography is a branch of applied mathematics, with a rich literature. I suggest you consult it first, or at least ask your question on a cryptography mailing list or newsgroup. Start at http://www.faqs.org/faqs/cryptography-faq/. (Well, it's dated at this point, but it will give you a hint of the flavor of modern cryptography.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt
Harald Tveit Alvestrand wrote: The only possible reason I can see for doing anything to the status of RFC 1032 is becaue the existence of the RFC is (wrongly) abused to try to force people into changing their behaviour with the argument The IETF says so. Certainly not, just read http://rfc-ignorant.org and the listing policy. It's a private service like abuse.net etc. Those people should stop taking the name of the IETF in vain. Those people are about as coherent as this list, and as far as I know they never talk about the IETF (excl. me). They discuss RfCs, mainly 2821 and 2142. Replacing 954 by 1032 last year, after 3912 obsoleted 954. Status UNKNOWN seems like a fine status to keep ACK, bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ltru] Re: Last Call: language root file size (long)
JFC (Jefsey) Morfin jefsey at jefsey dot com wrote: I am sorry to impose that kind of response - and a large number of mails. But this shows the problem to protect an open RD capacity against a chapel, which as some good points. And a non-profit RD against people sharing in a commercial competing consortium. Since most of M. Morfin's messages make at least passing mention of this supposed conflict between open and commercial interests -- the forces of good vs. the forces of evil, as it were -- I suppose some explanations about my own motives are in order. I do not have any commercial or financial stake in the success of the language-tag drafts. I am a software developer, working for a company that produces an internationalized software product, for (frankly) rather small values of internationalized. Since we are working with the .NET platform, most of us have at least some familiarity with what the documentation calls culture names, which are based on RFC 3066 but make use of some non-standard extensions. In addition to regular development, I am responsible for maintaining what we call code lists, which are basically resource files shared between systems that otherwise know little about each other. I got involved in the language-tag project at its early stages, partly to avoid repeating some of the misconceptions I had had years earlier about RFC 3066. I had been keeping track of changes to ISO 639 and 3166 for many years anyway, so when the concept of a comprehensive language subtag registry came up, I mocked up my own example registry that matched the description in the draft. That example eventually became the proposed initial registry. I have developed, on my own time and with no company assistance, a small utility program that generates and validates language tags according to the current draft. It contains a database that is compiled programmatically from the text registry (into a DLL). It is flexible in the sense that the database can be updated independently from the main program. It understands the concept of extended-language subtags, although none are defined in the current draft. The IETF may wish to consider this running code, or a working implementation, for purposes of evaluating the drafts, and if IETF members are interested in examining it to help with serious evaluation of the drafts -- not just to find reasons to tear it down -- I can make it freely available. (I have not released it yet, of course, because the RFCs on which it is based are only I-Ds.) Very importantly, this program is **NOT** a commercial endeavor. It could conceivably be made into one, or it culd be offered as freeware or shareware (although I have no specific plans to do either), but it could just as easily be converted to an open source project of the type often mentioned by M. Morfin. The point is that there is NO dichotomy between free (or open or non-profit) and commercial (or corporate) when it comes to the current drafts. The draft contains NO restrictions against open-source or non-profit implementation (I would think they would be strongly encouraged). There is nothing in the ABNF that prevents open-source development based on the proposed BCP. There are no IP constraints on any of the technology used in its development. Any existing protocols that make use of language tags, and stand to benefit from the proposed update, will benefit equally regardless of whether they are commercial or not. M. Morfin has argued that there are prevalent running code implementations that use his expanded language-tag syntax, which is not compatible with the syntax in the present draft. However, to date I have not seen any pointers to such an implementation, nor any evidence of the prevalence of this alternative syntax. Obviously any developer can write code that *does not conform* to a given standard, or proposed standard, but that says nothing about the standard itself, or about whether the non-conformant code or the syntax it does follow is somehow better. The arguments that RFC 3066 is widely ignored are specious as well; there are numerous examples of protocols that adhere to the RFC 3066 model. The fact that non-conformant implementations (like the culture identifiers) exist is not a justification for throwing away the model. To cite an example from another thread, we acknowledge that some mail software implements Reply-To poorly, but that does not mean the whole notion of Reply-To should be thrown away as irrelevant, or not supported by open RD solutions. I apologize for the length of this particular point, but I feel it is important. Not everyone who supports the draft does so out of commercial greed, and even those who happen to work for Big Commercial Behemoths might have higher motives. Some people just like the feel of an open software vs. closed software struggle, á la Richard Stallman or Eric Raymond -- note M. Morfin's reference to a chapel, evoking images of Raymond's The
Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02
In [EMAIL PROTECTED] Frank Ellermann [EMAIL PROTECTED] writes: John Glube wrote in mxcomp: I should have written: |The underlying benefit of e-mail authentication for senders |interested in e-mail delivery is to establish a framework that |supports certification and reputation services, both external |and internal to facilitate the delivery of ham, while rejecting |spam [1] That was not the main purpose of SPF. SHOULD check HELO was added in 2005, because it was always allowed and possible, and it makes sense for the reasons you have stated. The SHOULD check HELO was added in 2004, not 2005. This was changed to RECOMMENDED in 2005. But the main idea of SPF is to get rid of backscatter, numerous bogus bounces / challenges / other auto-responses to forged Return-Paths. With side effects, some hard, others desirable. The DKIM proto-WG is currently going through the process of trying to specify What is DKIM intended for? It's a good idea and one that the SPF folks skipped in 2003. So, I disagree that main idea of SPF is to get rid of backscatter and such. That is certainly *one* of the reasons that *some* (maybe even most) people had for promoting SPF, but certainly not the only reason. Other reasons include the desire by domain owners to not have their domain name forged in the MAIL FROM and HELO domains, whether they caused backscatter or not. Also, by creating identities that could be verified, you could make more reliable use of whitelists and blacklists. Another is that it could be used as a basis to help protect the 2822.From: header, if you can correctly identify the cases where the 2821.MAILFROM will differ from the 2822.From:. I suspect that there are going to be several other answers from other SPF supporters. If your only goal is to get rid of backscatter, things like SES do a much better job. -wayne ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02
In [EMAIL PROTECTED] Bruce Lilly [EMAIL PROTECTED] writes: This is an important point; the SPF-classic draft was announced to the ietf-822 and ietf-smtp mailing lists where there was some discussion on that very point. While the ID-tracker state indicated intended status of Experimental, the author stated that he was very reluctant to debate issues of controversy with the technical specification, and that his goal was to document a de-facto standard [his words]. What I said both times I submitted the spf-classic I-D for review by various IETF mailing lists was, in full: I realize that the whole subject of SPF (and similar systems) has a certain amount of controversy to it, but for the purposes of this draft, I am very reluctant to try debate these issues. The goal is to document a de-facto standard. Debates about better techniques, why SPF is evil, etc. are probably best discussed on things like the IRTF ASRG list, SPAM-L, the NANAE newsgroup, or on spf-discuss on a separate thread/subject. (See http://www.imc.org/ietf-smtp/mail-archive/msg01404.html and http://www.imc.org/ietf-smtp/mail-archive/msg01870.html) There were quite a few technical errors that were corrected because of the reviews in ietf-822, ietf-smtp and the dnsext lists. I even made an editorial change to the draft because Bruce didn't think that one RECOMMENDED item applied to only those domain owners that chose to participate in SPF. My intent was to simply not cause the various mailing lists to be flooded with off-topic discussions, especially those that have had a history of never being resolved. -wayne ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ltru] Re: Last Call: language root file size (long)
I wrote: 3. The proposed initial registry contains subtags based only on the existing standards: ISO 639-1 and 639-2, ISO 3166-1, ISO 15924, and United Nations M.49, as well as variant and grandfathered subtags based on the RFC 3066 registry. Should have been: variant subtags and grandfathered tags There is no such thing in the draft as a grandfathered subtag. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: STD (was: Last Call: 'Tags for Identifying Languages' to BCP)
rd afrac rd at afrac dot org wrote: - I supported the proposition of an African searcher (they treated of troll) to reconcile the desire of a strict ABNF expressed by the WG affinity group and the users, RD and innovation (following ISO evolution) support to use the URI-tags RFC in proposing first to use the private use area. As indicated, a remark shown me it was a wrong choice, the private use area also addressing other needs. Merriam-Webster OnLine defines affinity group as a group of people having a common interest or goal or acting together for a specific purpose (as for a chartered tour). Exercise for the reader: Explain why this is a bad thing for an IETF Working Group. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
