Re: bozoproofing the net, was The Value of Reputation
Jeffrey Hutzelman wrote: On Monday, January 02, 2006 08:51:20 PM -0800 Dave Crocker [EMAIL PROTECTED] wrote: I don't believe we have ever turned winning by exhaustion or winning by intimidation into virtues, even though those techniques are Actually we have. It is used with some regularity by various folk in IETF management, in lieu of honoring the requirements of plausible that I provided above. If that's true (and I'm not expressing any opinion as to whether it is), that doesn't make it a virtue. Note the change that Russ is making to the charter. I think a lot of people might be missing a key point about how our process works. In fact, it's looked that way to me for a while, and so since you bring it up, I'll try to clear things up for anyone who might be confused. Please don't think I'm singling you out... [...] In other words, Russ is within his rights to make changes to the charter he is willing to bring to the IESG -- especially in a case such as this where the proposed charter has been discussed so publicly that the rest of the IESG cannot possibly be deceived into thinking the charter Russ brings them is exactly the one the DKIM proponents proposed. I agree. As I believe do a number of other dkim proponents, most of whom are, I'd say, much less concerned about these (IMO mainly process-nit) issues with the charter text and who'd like to get on with the work in a working group with all that that entails - most especially including establishing wg-consensus on the text of the chartered deliverables. Stephen. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call: draft-salowey-tls-ticket-06.txt
Bernard Aboba wrote: From what I can see, the Ticket structure does not uniquely identify the ticket type or ticket version, so that there is no easy way for the server to determine what type of ticket has been submitted to it, or whether the client is using the recommended format or not. The server checks the mac in the last 20 octets, and if this is valid, then it decrypts the encrypted_state. However, if the client were using the same mac, but a different ticket format, the mac could check out, but the StatePlaintext would not match. A Ticket Type/Version field would make it clear to the server whether it is handling a Ticket of known type. The MAC will check out only if the servers are using the same key. If the servers regularly generate new keys (as is suggested in the document, although not with an uppercase keyword), this implies either that they have different keys (so MAC won't match and the server won't attempt to interpret the ticket) or there's some server-to-server key distribution mechanism between cluster members. Any server-to-server protocols are very much beyond the scope of this document, so we don't expect any interoperability there. But perhaps the document should contain more explicit requirements about key management (e.g. the keys used to protect the tickets must not be used for any other purpose, including sharing with other non-identical nodes)... What the specification does not currently have is a detailed instructions for those who want to design their own ticket format section. Personally I do not think it would be a very useful thing to include. It might actually encourage people to design their own ticket formats, and there's no way the section could cover all the possible ways to get things wrong :-) The problem is that without normative language, almost any implementation can claim compliance, regardless of whether they use the recommended ticket format or heed the security considerations. It's certainly true that implements all the MUSTs in the document does not imply the system is secure, but that applies pretty much to any document (unless it says the system MUST be secure :-). The server might at some point want to change algorithms for all clients, no? Or might it not want to be able to verify that the ticket was constructed using algorithms that it supports? Or even that the ticket utilizes the format recommended in this specification, as opposed to another format? Yes, changing the algorithm for all clients is a realistic possibility. But if you generate new keys when you change the algorithm (which you really should do anyway), then it's enough to verify that the MAC is correct (if it isn't, it isn't really important to know why it was not correct). The recommended ticket construction does include a timestamp saying when the ticket was issued. If a client submits a ticket that is unacceptable to the server for some reason (expired, not the right format, etc.) does it get back an error message letting it know whether to continue to cache the ticket? For example, if the server understands the ticket and says it has expired, this is different from not being able to understand the ticket. Currently, there are not special error messages to communicate why the ticket was not accepted, since I don't think the client really needs to know the reason. If the ticket is not accepted, the server simply starts full TLS handshake, and once that's done, may either send a new ticket, or indicate that it doesn't want to use stateless session resumption this time (by sending a zero-length ticket). Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call: draft-salowey-tls-ticket-06.txt
Bernard Aboba wrote: If a client obtains a ticket from Server A, running software version X, and then sends it to server B, running software version Y, how is Server B supposed to figure out that it is the wrong version? This becomes a problem only if the servers are using the same key to MAC the tickets. (If they're using different keys, the MAC won't match anyway, and server B doesn't need to know what version server A is using.) But you're quite right, this could be a problem if one shares the keys in heterogeneous environment, and the document should probably warn about this. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call: draft-salowey-tls-ticket-06.txt
Pasi, The MAC will check out only if the servers are using the same key. If the servers regularly generate new keys (as is suggested in the Yes. But perhaps the document should contain more explicit requirements about key management (e.g. the keys used to protect the tickets must not be used for any other purpose, including sharing with other non-identical nodes)... This change would be useful, I think. I would also like to see the MAC/encryption-keys-are-independent requirement that Bernard was talking about. Yes, changing the algorithm for all clients is a realistic possibility. But if you generate new keys when you change the algorithm (which you really should do anyway), then it's enough to verify that the MAC is correct (if it isn't, it isn't really important to know why it was not correct). Doesn't the key_version field also provide a hint as to whether the ticket is something that you can recognize? Presumably, you could have multiple versions, if you wanted to support old/new algorithms and associated keys for a while... In any case, it seems that it would be useful to add a requirement that new keys and key_version values be generated upon algorithm/format changes. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: EAP Method Update (emu)
Clint Chaplin wrote: Has an email list been set up for this effort yet? We are currently operating under the secmech list: General Discussion: [EMAIL PROTECTED] To Subscribe: https://www1.ietf.org/mailman/listinfo/secmech Archive:http://www.ietf.org/mail-archive/web/secmech/index.html But a new list [EMAIL PROTECTED] will be created upon WG approval. Stay tuned for subscription instructions. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: participation sans meeting attendance (was RE: Alternative formats for IDs)
On 1/2/06 11:32 PM, Jeffrey Hutzelman [EMAIL PROTECTED] wrote: I think we're doing better on this front than we have in many years. The technical support for remote participation really has become terrific. Some sessions are run with great sensitivity to remote participation, others are not - it depends on the chairs. However, on the other hand it does seem as if groups have become more likely to make final decisions during meetings and not on mailing lists. Rarely you run into the perfect storm of no jabber scribe, poor microphone placement, and decisions made in meetings only, but it does happen. I haven't travelled to a meeting in about a year but I have participated remotely, and although the handling of remote participation has been inconsistent from working group to working group overall it's been pretty good. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call: draft-salowey-tls-ticket-06.txt
The MAC will check out only if the servers are using the same key. If the servers regularly generate new keys (as is suggested in the If there is no rnormative requirement that the MAC field actually contain a MAC, how can we assume this? And if there is no algorithm indication, how do we know how long the MAC field is? Doesn't the key_version field also provide a hint as to whether the ticket is something that you can recognize? If the key_version field was globally and temporally unique (for example, if it included the server name + a counter) then it would provide that information. But it's just a 32-bit integer. If servers start at zero, the chance of collision will be qu ite high. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Troubles with UTF-8
Tim Bray wrote:
On Dec 28, 2005, at 12:46 PM, Randy Presuhn wrote:
Reserving NUL as a special terminator is a C library-ism. I think that
history has shown that the use of this kind of mechanism, rather than
explicitly tracking the string's length, was a mistake.
I guess variably lenght V-records of type
string {int type,
int length,
int data[] );
would be horror. That will lose you 4 bytes per word and 2 bytes for
every printable sign.
C-ASCII Randy Presuhn = 14 char + '\0'.
Compare it to
9, R, a, n, d, y,
9, P, r, e, s, h, u, n
That is 28 characters now. No alternative.
I used to think so too, but I don't any more; twenty years of doing
text processing has convinced me that C's null-terminated strings
simply cannot be improved on in a low-level programming language. For
more on the subject see http://www.tbray.org/ongoing/When/200x/
2003/04/13/Strings -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call: draft-salowey-tls-ticket-06.txt
The MAC will check out only if the servers are using the same key. That's not necessarily true. Since the ticket is not self-describing. and there is no normative language relating to ticket construction, there is no guarantee that implementations will put the MAC field in the same place or use the same algorithm. This could be fixed by including a globally and temporally unique ticket identifier, and mandating that the MAC field be put at the end. It's certainly true that implements all the MUSTs in the document does not imply the system is secure, but that applies pretty much to any document (unless it says the system MUST be secure :-). While it's certainly true that normative language doesn't guarantee security, most specifications do use normative language, if only to pin down some basic features of the specification. It is quite possible for this specification to allow innovation along many dimensions, by mandating a few critical items, enough to avoid interoperability problems, and leaving the rest open. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call: draft-salowey-tls-ticket-06.txt
Bernard Aboba wrote: The MAC will check out only if the servers are using the same key. That's not necessarily true. Since the ticket is not self-describing. and there is no normative language relating to ticket construction, there is no guarantee that implementations will put the MAC field in the same place or use the same algorithm. This could be fixed by including a globally and temporally unique ticket identifier, and mandating that the MAC field be put at the end. If the servers use different keys, it does not matter where the MAC field is placed, or whether the same or different algorithm is used. If it would, the MAC algorithm would be seriously flawed, and totally unsuitable for this use even if the field locations were fixed... It's certainly true that implements all the MUSTs in the document does not imply the system is secure, but that applies pretty much to any document (unless it says the system MUST be secure :-). While it's certainly true that normative language doesn't guarantee security, most specifications do use normative language, if only to pin down some basic features of the specification. It is quite possible for this specification to allow innovation along many dimensions, by mandating a few critical items, enough to avoid interoperability problems, and leaving the rest open. I don't share your enthusiasm about using the uppercase RFC2119 keywords, but would adding a couple of requirements along the following lines satisfy your concerns? The key(s) used to protect the tickets - MUST be generated securely, taking [RFC4086] into account - MUST be at least 128 bits in strength - MUST NOT be used for any other purpose than generating and verifying tickets of a particular ticket format in a single logical TLS server (which may encompass multiple CPUs or hosts in a distributed environment). - MUST be changed regularly - MUST be changed if the ticket format changes - MUST NOT be used with multiple cryptographic algorithms Since the document is an extension of TLS session resumption (which happens between a single logical TLS client and server who have been in contact before), I don't think we need to include interoperability between servers in the document. All that is required is that a server can recognize whether the ticket is something it sent out earlier. The simplest way to do this is to MAC the ticket with a key known only to the server; addiong globally unique issued-by-server-known-as-X fields is not necessary for this purpose, and would IMHO just encourage clients to inspect the tickets and hurt interoperability. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: EAP Method Update (emu)
Pekka, Is there a particular reason why the proposed charter does not mention EAP-TTLS? I know very little about different EAP types, but as a potential operator and user of EAP, I'd definitely want to see focus on something like EAP-TTLS. Given that EAP-TTLS seems to be becoming an industry standard in certain scenarios, it would be useful to clarify the relation of the work of this proposed WG wrt EAP-TTLS in the charter. The relation may already be obvious to those who've been working on that space more, but as an EAP user, I'd like to make it explicit to ensure folks are on the same page.. First, some background on the difference of EAP TLS vs. EAP-TTLS. EAP TLS uses TLS mutual authentication (typically with certs). In contrast, tunneled EAP methods, such as EAP-TTLS or PEAP employ TLS and an inner method. Typically, the outer TLS authentication is for the server only, and used to protect an inner authentication that may happen, for instance, with passwords. Tunneled EAP methods typically have also additional built-in functionality, for instance, to exchange various parameters for configuration and verification purposes. EAP-TLS is an existing Experimental RFC that the EMU WG is chartered to update and extend. Tunneled EAP methods have been described in drafts, and there are a few different ones and they have a few different versions. There has been some discussion previously about working on tunnel methods in EMU. Assuming there'd be willing contributors change control would be given to IETF, this would be a useful area to work, since, as you point out, these are widely used methods. Drawbacks include a lot of existing deployment with sometimes incompletely documented and proprietary methods. I also worry about doing too many things in EMU at the same time; we are already on the limit. But once work items get completed, new things can be worked on. The EAP TLS update should be fairly easy and non-controversial task, for instance, so hopefully it is completed soon. In any case, the charter does include work on password-based methods. The specific arrangement for how passwords are to be used is TBD, but tunneled TLS- like methods are one possibility. While password-based client/cert-based server authentication is a special case of what existing tunnel methods can do, it may be the most important case. If we succeed in defining these methods, one can hope that the new method would start to take over some existing TTLS et al usage. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
agreed. Tony Hansen [EMAIL PROTECTED] John Levine wrote: Here is the revised proposed charter text: Thanks for pulling this together. If I had unlimited time to waste, I might niggle about a word or two, but it's fine as is, and I look forward to moving ahead and getting some work done. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On Tue, Jan 03, 2006 at 06:40:41AM +0200, Yaakov Stein [EMAIL PROTECTED] wrote a message of 83 lines which said: Which is exactly the reason all the other SDOs use MS Word for input and PDF for output. Blatantly false. For instance, W3C and Oasis do not use MS Word. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Support for cooperative work (Was: Alternative formats for IDs
On Tue, Jan 03, 2006 at 08:27:43AM +0200, Yaakov Stein [EMAIL PROTECTED] wrote a message of 31 lines which said: Neither of these has any support for cooperative work. Support is not in the format (what we discuss here) but in the tools. There are a lot of tools for cooperative work with text / ASCII, text / UTF-8 or XML files (CVS, xmldiff, diff, Subversion, darcs, Trac, etc). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On Tue, 3 Jan 2006, Stephane Bortzmeyer wrote: On Tue, Jan 03, 2006 at 06:40:41AM +0200, Yaakov Stein [EMAIL PROTECTED] wrote a message of 83 lines which said: Which is exactly the reason all the other SDOs use MS Word for input and PDF for output. Blatantly false. For instance, W3C and Oasis do not use MS Word. It depends on how one defines all other SDOs. :) or concensus. Maybe like .us politicians redefine words to suit their own meanings. -- ~Randy [agreeing with Stephane] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Working Group chartering
Jeffrey, (I have changed the subject line, so that this discussion is explicitly NOT about any current IETF chartering activities. I hope folks will not take my comments as having any implication about any of those efforts or discussions about them...) I think a lot of people might be missing a key point about how our process works. What makes things particularly challenging is the difference between Procrustean attention to documented rules, versus applying them in an integrated manner with subjective assessment of the pragmatics of being productive. Any organization that strictly resolves disputes based on the letter of its laws quickly alienates is workforce. When we wrote the rules regarding chartering, the intent was to have the cognizant AD conduct whatever discussion were needed to create a working group that would be productive. This is inherently a fuzzy process, so it was -- and remains -- important to avoid over-documenting the procedure. For example, an AD who entirely ignores the concerns and desires of those who will do the bulk of the work risks having a working group without workers. The pragmatics, therefore, require the AD to try to juggle various political, technical and project management concerns, and put forward a charter that they feel will offer the best chance at productive working group output. Frequently -- maybe usually -- this is primarily through a private dialogue among those who will form the small core of the working group effort, including likely chairs. However it is not uncommon for a public dialogue to be conducted. For example, a BOF usually includes a review of candidate charter text. That the open group's consensus is not binding on the AD merely indicates the delicate nature of chartering, rather than the irrelevance of that consensus. This ability to determine what work will be done and under what terms is a fundamental part of what it means to steer; without it, the IESG would not be much of a steering group. Actually, this highlights why steering group is exactly the wrong term for the IETF process management team. They do not initiate work and they are not primary contributors to that work. Hence, they do not really steer anything. When the IESG tries to act like it does, they often find no workers and a mass of dissatsfaction. The job of the IESG is to facilitate the initiatives of others and to ensure enforcement of useful quality assurance. It's beneficial to apply constraints like only considering solutions with domain-level granularity, or only addressing how to _provide_ identity information and not what to do with it. Particularly given the IETF's previous experience with attempted anti-spam work, I think such constraints are necessary to narrow the problem space to one for which a working group will produce something in a finite time. Besides being necessary, those constraints are also acceptable because while they limit _this_ working group to solving one piece of the problem, there is no implication that other working groups will not be chartered to work on other pieces. And, while _this_ working group is constrained to a particular approach, there is no implication that other approaches might not also be tried. all of the above is nicely said, as comments about a class of working group startup efforts. What I do _not_ think is reasonable is a demand that the working group be constrained to produce exactly the protocol proposed, making changes only if absolutely necessary. And here is where we have the major disconnect. Working groups start from a wide variety of places. Some start with an idea. Some with a detailed proposal. Some with a detailed specification and some with existing and deployed technology. When a working group starts, it must make the strategic decision about how much prior work to preserve, versus how much new work to encourage or require. There are obvious and significant trade-offs in this choice. What is essential is that the trade-offs get serious consideration and that the choice be appropriate to the particular situation. It absolutely is NOT true that all chartered working groups must be allowed to throw away any and all prior work. The loss of invested community effort and the loss of momentum would be disastrous. At the least, an effort that seeks to use existing technology needs to explain clearly and convincingly what needs to be preserved. Equally, any efforts to deny the stability of re-using that work must make a compelling and concrete case for the changes that are needed. Note that the XMPP case is somewhat different from this one. Remembering that this new thread is about a general issue, rather than debating a particular working group effort, I'll comment on the particulars of your reference: In that case, a working group was formed to adopt an existing technology from another process,
Re: WG Review: Domain Keys Identified Mail (dkim)
Here is the revised proposed charter text: Thanks for pulling this together. If I had unlimited time to waste, I might niggle about a word or two, but it's fine as is, and I look forward to moving ahead and getting some work done. Complete ageement here. This is plenty good enough to move forward. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
--On Tuesday, 03 January, 2006 06:47 +0200 Yaakov Stein [EMAIL PROTECTED] wrote: The downside is that when a group is working on a document in Word, anyone not having the SW would not be able to directly contribute - but joint work is not really practical using any system without tracking anyway. That is an interesting observation. It must be true since you say it is. However, I wonder what it means that I have my name, as author or editor, on, by rough count, 27 RFCs. And I've been a major contributor (of text, not just ideas, for a few more). Of those, all but about three were collaborative, with multiple people contributing text. And, of that group, the number that started in Word, including one of those non-listed-editor collaborations, was two. I guess the other 25+ documents must not have been practical to produce. At one level, I'm sympathetic to what you are saying and trying to accomplish. While there are many characteristics of Word that I dislike, I like its tracking facilities and ability to turn tracking displays and marginal comments on and off. Used properly, I find them much more satisfactory than anything I've been able to do with CVS-like and Diff-like systems: the latter are better at identifying what has been changed (although that can be effectively simulated in Word by letting it generate change tracking by comparing two documents) but far worse at recording and identifying the reasons why the changes were made. Unfortunately, even if one ignores most of the issues with proprietary format and costs, it is hopeless for IETF use in managing working documents and RFCs. Among the problems: (1) Its template mechanism is very version-sensitive and fairly fragile. If one makes template or option changes to accommodate IETF needs, one cannot then go back and forth with the formatting requirements of day job documents without risking making a royal, and essentially irreversible, mess. (2) Its Style model is even more version-sensitive and even more fragile. It is also badly documented and idiosyncratic. But it, or major template changes, or both, are necessary if one is going to produce IETF documents that correspond to RFC Editor norms (and I'm not just talking about ASCII output). (3) Its cross-reference model is so smart in terms of what can be referenced, what header styles it can be used with, etc., that cross-references in RFC Style and within RFC objects are not consistently possible. The facilities of WordPerfect 4.2 in this area, nearly two decades ago, were far superior, I believe because of less of an attitude of we know what you need and, if we don't supply it, you don't need it. (4) Others have pointed out the versioning problem in terms of reading documents, but it is worse than that. I've seen document formatting and structure destroyed beyond recognition or recovery by the simple mechanism of being moved back and forth among authors who are using different version of Word, even when Word 2000 is the oldest of them. I know how to mitigate that problem but it would require far more drastic changes in how the IETF does business than merely switching working document formats. (5) Other than change-tracking, Word has very little built-in collaboration machinery. I have the impression that there are even fewer such facilities in recent versions than in earlier ones. Instead, the strong collaboration facilities require even more expensive versions of Office, use of Outlook for email, and other client and server conventions that would be far more problematic for the IETF. (6) While I had high hopes for the XML output from Word (again, available only with Office Professional and above, if there is an above), the 2003 version turns out to be one of the stranger things I have every seen. The XML output from Office 12 is supposed to be much better -- I haven't seen it-- but it is, again, incompatible. That is by no means my entire list, but it is indicative. And others may have other lists or entries. For all of those reasons and others -- and I am still concerned about costs and share the concerns of others about proprietary and changing formats -- actually IETF use of Word seems to be to be a non-starter. I do believe that, if you want to do initial document preparation in Word, you should be able to do that. As others have suggested, no one I know of is really interested in standardizing on or requiring a particular editor. But, to do so, you need to be able to produce an editable format that is no worse than ASCII. You may have better ideas, but,
RE: Alternative formats for IDs
Second, your assumption that other SDOs have been able to blissfully make use of private formats like MS Word without incident is simply untrue. One obvious counterexample I know of is the CCITT/ITU, which has in the past used MS Word as a distribution format for many of it's documents. I have quite a few of these documents on hand and occasionally need to refer to old versions of them, but when I try and read them using modern tools the results are rarely good. Many of these documents simply refuse to open, sometimes crashing the tool I'm using, while others do open but are misformatted, sometimes to the point of being illegible. [YJS] I think that something has been lost in the translation here. Indeed it does: You appear to be unfamiliar with the specifics of your own proposal, which quite clearly calls for MS Word as both an INPUT and OUTPUT format. ITU (I have participated in the ITU-T for many years, and ALWAYS sent in my contributions in Word) ONLY accepts contributions in Word and ONLY works on documents in Word (using ITU designed templates). I don't know and don't particularly care what process the ITU uses for this. My comments were directed at the notion of using Word as an output format for RFCs. However, I note in passing that at least one other person has stated that the procedure the ITU uses does not, in their opinion, work well at all. I cannot say I'm surprised by this. The OUTPUT documents are available in Word and PDF, with PDF the recommended format (due to Word's bad habit of changing pagination when using different page sizes, etc). The PDF output should be readable indefinitely. That appears to be true today. It wasn't true in the past. Many of the ITU specifications I have are in Word format only. The Word format is mainly there for people who may need to work on updates of the standard (unlike RFCs, ITU Recommendations are updated). Except when it's the only choice, in which case everyone who wants to read the thing has to put up with it. If such a Word doc is unreadable for anyone needing it, the secretariat has tools to convert it. I am extremely skeptical that the ITU Secretariat stands ready and willing to assist any random schlub who comes along with a handful of old ITU documents they acquired several decades back and can no longer read. Try CVS or SVN and diff - works for everyone. Sorry, although I have such toys on my home computer I am not allowed to install such unsupported SW on my work computer. So? As it happens the place where I work has rules severely restricting the use of various Microsoft products. CVS, SVN and diff, OTOH, are all fully supported tools in my work environment. As Russ pointed out, it is no more reasonable to expect you to be swayed by the vagarities of my workplace than it is for me to give a damn about those of yours. The intersection of the tools allowed by everyone's workplace is pretty much guaranteed to be the empty. In any case, since I've seen not even the slightest hint of any support for your proposal to adopt proprietary formats for I-Ds and RFCs, it appears that further discussion is a waste of time. So this will be my final message on this topic. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
-- Lets go ahead and ask then - -- Does anyone else think that IETF should allow documents which -- format/structure is not publicly known as one of the ways to -- distribute IETF specifications? Clarifying that publicly known means well defined and publicly available, I would answer no... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
From http://www.itu.int/ITU-T/edh/faqs-docsub.html When submitting a document which contains figures, it is highly recommended that the figures be created using a graphic software and inserted into the document rather than creating the figure using the default Picture Editor in Word. Drawings made using Picture Editor do not convert properly in different versions Word for Windows and in some cases, the figures do not appear at all. In cases where the author has used the Picture Editor, the author must ensure that all the elements or objects in the figure are grouped (defined as one figure) to avoid objects being re-aligned when the margins or paper size are modified. Not exactly confidence inspiring. Good thing they highly recommend not using the default Picture Editor in Word. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Value of Reputation
John Leslie wrote: Nathaniel Borenstein [EMAIL PROTECTED] wrote: On Dec 24, 2005, at 4:09 PM, Douglas Otis wrote: Reputation remains the only solution able to abate the bulk of abuse. ... I think most of us pretty much agree about the critical role of reputation. I've noticed a lot of what I call lip service about the critical role of reputation. To say this differently, many folks seem to think you can choose a reputation system almost at random, and it's sure to improve your signal/noise ratio, unless you've chosen the wrong one. (which, I suppose, is a tautology...) But, in my view, we have no basis to choose the right one unless we have a good understanding of what it measures and a workable idea of how to end run when it falsely rejects good messages. I completely agree that reputation has a critical role (although accreditation is important in many situations, as Phill has pointed out, and should not be ignored). However, I have come to believe that there is a great deal of subtlety below the surface of any good reputation system: - Preventing abusers from gaming the system to get good scores - Preventing attackers from damaging the reputations of others - Defending the reputation system against legal actions from those who feel they have been hurt - Making it all work within the law, considering privacy laws, restraint of trade, and so forth, considering that the laws governing this vary by jurisdiction For this reason, I don't think the operation of reputation systems themselves should be defined by IETF; different users will have different needs. However, standard protocols for communicating with reputation systems will be needed, and this is a very important area for IETF to address. Transaction rates for lookups will be high, and careful protocol design is needed. The use of standard protocols in this area will allow clients to pick a suitable reputation service, and to change services without changing their infrastructure. Both reporting and query protocols will need to be defined. Much of this applies to accreditation services as well, although there are some different requirements (negotiating an accreditor to use between sender and recipient/verifier, for example). -Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about the Neustar logo on www.ietf.org
At 00:15 03/01/2006, John Levine wrote: NeuStar is the .us Registy and has entered into an open root agreement with the GSMA, supporting the .gprs TLD. That the IETF pays to host a link to them may certainly be perceived as a political signal. Oh, no, not this again. Neustar's .gprs TLD exists only on a special purpose private network disjoint from the public Internet, used for GSM signalling and invisible to anyone who doesn't run a GSM phone switch. Dear John, do you agree I ask your head the day I can reach .gprs names from my PC? It is not the network that GSM phone users see when they use web or mail services over their phones. I don't care what names the GSMA uses on their private network, and I don't see any reason that anyone else would, either. ICANN has suggested the IETF to run a testbed on this kind of evolution. It even suggested to use classes as per the adequate proposition of John Klensin. The IETF prefered not to. There may be reasons not to like Neustar, but the fact that they happen to provide network infrastructure to phone companies is not one of them. No reason to dislike NeuStar. They introduce competition where there is none. IMHO this is a blessing for the native Internet and a challenge for the international network and the IGF. What is dangerous is to consider all this neutral. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
optional clip screening in H.323 supplementary service
H.323 recommendation has supplementary services defined in H.450 ITU recommendations. One of them is H.450.3 call diversion service. In many H.323 devices H.450.3 implements clip screening. This function makes a manipulation of CLI (calling line identification) of the caller: if A (generic user) calls B (my network client) and B has a H.450.3 call forward unconditionally to C (mobile phone of B), C receive a call with the CLI of A A -- B - C |_CLI_| Usually this scenario is correct but in a case where billing is based on CLI this is a problem because the call is generated from A (which isn't a client of my network) and so i haven't the billing of the call. Without clip screening: A -- B - C |___CLI| |___CLI___| C receive a call generated from B (my client) and so the billing is ok. Is there a protocol/reccomendation which implements this function? What is your opinion? Thanks. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Value of Reputation
Jim Fenton [EMAIL PROTECTED] wrote: John Leslie wrote: But, in my view, we have no basis to choose the right one unless we have a good understanding of what it measures and a workable idea of how to end run when it falsely rejects good messages. I completely agree that reputation has a critical role (although accreditation is important in many situations, as Phill has pointed out, and should not be ignored). However, I have come to believe that there is a great deal of subtlety below the surface of any good reputation system: - Preventing abusers from gaming the system to get good scores This, IMHO, can never be standardized. We can ask for a web page (subject to change without notice) detailing what is measured, but I doubt we could even standardize the questions such a web page should answer. - Preventing attackers from damaging the reputations of others This is an area which could benefit from standardization, IMHO. I'm not sure, though, whether consensus is attainable. I think CSV did a reasonable job here. While I think SPF fails at this, I doubt we'd ever get the SPF folks to agree. - Defending the reputation system against legal actions from those who feel they have been hurt I think we should steer clear of this issue. - Making it all work within the law, considering privacy laws, restraint of trade, and so forth, considering that the laws governing this vary by jurisdiction I see no point in trying to standardize for conflicting jurisdictions. For this reason, I don't think the operation of reputation systems themselves should be defined by IETF; different users will have different needs. I entirely agree. However, standard protocols for communicating with reputation systems will be needed, and this is a very important area for IETF to address. I would very much like to do so. Transaction rates for lookups will be high, and careful protocol design is needed. The use of standard protocols in this area will allow clients to pick a suitable reputation service, and to change services without changing their infrastructure. Ease of changing reputation services trumps most other considerations, in the real world. Both reporting and query protocols will need to be defined. Reporting, IMHO, needs a standardized minimal-set, not a full set. Query protocols should see _a_ standard query, which need not necessarily return all available information. Much of this applies to accreditation services as well, although there are some different requirements (negotiating an accreditor to use between sender and recipient/verifier, for example). In CSV, we standardized a way for sender to advertise accreditor(s). I'm not sure if anything beyond that will be practical. The question of standards for reputation and accreditation, IMHO, deserves IETF work and could deliver great value. But to be clear, I do not think it belongs in DKIM. -- John Leslie [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Value of Reputation
John Leslie wrote: The question of standards for reputation and accreditation, IMHO, deserves IETF work and could deliver great value. But to be clear, I do not think it belongs in DKIM. I strongly agree. By CCing the ietf-dkim list on my message I didn't mean to imply that the work belongs there. -Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Troubles with UTF-8
The morality of string delimiters vs. character counts is a debate that has been going on for some 40 years! Some things never change... ;-) Bob Braden ... I think the use of explicitly encoded length, rather than special terminator or deliminator sequences, is simpler to code and debug, as well as being more robust in avoiding buffer overflow problems, etc. ... Reserving NUL as a special terminator is a C library-ism. I think that history has shown that the use of this kind of mechanism, rather than explicitly tracking the string's length, was a mistake. Randy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Troubles with UTF-8
On 12/23/05, Tom.Petch [EMAIL PROTECTED] wrote: A) Character set.UTF-8 implicitly specifies the use of Unicode/IS10646 whichcontains 97,000 - and rising - characters.Some (proposed) standards limitthemselves to ..007F, which is not at all international, others to -00FF, essentially Latin-1, which suits many Western languages but is nottruly international.Is 97,000 really appropriate or should there be a definedsubset?Why should there be a subset? You really really dont want to go into a debate of which script is more important then the other. B) Code point. Many standards are defined in ABNF [RFC4234] which allows code points to be specified as, eg,%b00010011 %d13 or %x0D none of which areterribly Unicode-like (U+000D).The result is standards that use one notationin the ABNF and a different one in the body of the document; should ABNF allow something closer to Unicode (as XML has done with #000D;)?Following RFC4234, Unicode code point U+ABCD will just be represented as %xABCD. I do not see the problem you mention or am I missing something? C) Length. Text is often variable in length so the length must be determined. This may be implicit from the underlying protocol or explicit as in a TLV.Thelatter is troublesome if the protocol passes through an application gatewaywhich wants to normalise the encoding so as to improve security and wants to convert UTF to its shortest form with corresponding length changes (Unicodelacks a no-op, a meaningless octet, one that could be added or removed withoutcausing any change to the meaning of the text). While the simple byte counting obviously wont give you the accurate length of the text (since one character in Unicode maybe represented by one or more bytes), it is fairly trival to write a script to count the length of the text accurately. Heck, perl 5.6 onwards even support Unicode natively.Other protocols use a terminating sequence.NUL is widely used in *ix; some protocols specify that NUL must terminate the text, some specify that it mustnot, one at least specifies that embedded NUL means that text after a NUL mustnot be displayed (interesting for security).Since UTF-8 encompasses so much, there is no natural terminating sequence.NUL is defined in Unicode btw but I am disgressing; You already started with a wrong foot if you think UTF-8 as some sort of programming encoding scheme rather then what it is; an encoding scheme for a character reportairs. D) Transparency.An issue linked to C), protocols may have reserved characters, used to parse the data, which must not then appear in text.Some protocolsprohibit these characters (or at least the single octet encoding of them),others have a transfer syntax, such as base64, quoted-printable, %xx or an escape character ( \ %).We could do with a standard syntax.In those cases, Unicode U+ABCD or ANBF %xABCD do nicely. Why do we need another one? E) Accessibility.The character encoding is specified in UTF-8 [RFC3629] whichis readily accessible (of course:-) but to use it properly needs reference toIS10646, which is not.I would like to check the correct name of eg hyphen-minus (Hyphen-minus, Hyphen-Minus, ???) and in the absence of IS10646 amunable to do so.In absence of a dictionary, I couldn't understand most of the words you used in an RFC. OMG, what should I do? http://www.unicode.org/charts/-James Seng ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
Clarifying that publicly known means well defined and publicly available, I would answer no... and if it is restricted to mean open description so that you could write your own editor to read and write this format ? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Troubles with UTF-8
Tim Bray wrote: That problem is that Unicode is stateful with complex and indefinitely long term states Has this ever caused a real problem to a real programmer in real life? Yes, of course. State information preserved between lines is really annoying. But, you miss the point in my original mail: : Unicode is not even finite state, which means some pattern : matching and normalization problems are hard or insolvable. that is, with Unicode, you can not search strings in reasonable amount of time. I have written a whole bunch of mission-critical code that reads and generates UTF-8, and any correct implementation will have to deal with the fact that there is no necessary connection between the number of glyphs on the screen and bytes in its encoding. You completely miss the point. It has nothing to do with the long term state. It would be perfectly reasonable for an implementation to declare a limitation, for example that it will not process than 32 trailing modifiers on any character, and this would not cause problems in production because sequences of such a length do not occur in the encoding of any known text. I said long term state, which, of course, is not confined in a character with or without modifiers. Which is to say, Ohta's statement about statefulness is true, but the conclusion that this is a problem is erroneous. -Tim Instead, your statement: I have written a whole bunch of mission- critical code that reads and generates UTF-8 is untrustworthy. Of course, it is perfectly reasonable for an implementation to declare a limitation, for example, that it will not process non-ASCII characters, which may also be the assumption of your code. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Nominees for IAOC seat to be appointed by the IESG
As described in BCP 101 (RFC 4071) and BCP 113 (RFC 4333), the IESG and the IAB each select one person for a two-year IAOC term in alternate years. This year, the IESG will select one person for a term ending in spring 2008. Following the call for nominations which ran from November 30 through December 23, 2005, the IESG received two nominations of people who are willing to serve. They are: Kurtis Lindqvist Jordi Palet Martinez The IESG expects to make a decision on or before February 3 (prior to the expected date at which the Nomcom will select its IAOC nominee). If any member of the community wishes to make confidential comments on one or both of these candidates, please write to [EMAIL PROTECTED] before the end of January. Brian Carpenter ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
