Re: Troubles with UTF-8

On Dec 28, 2005, at 5:05 AM, Masataka Ohta 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? I have written a whole bunch of mission-critical code that reads and generates UTF

Re: Troubles with UTF-8

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 used to think so too, but I don't any mor

Re: bozoproofing the net, was The Value of Reputation

--On søndag, januar 01, 2006 22:53:15 -0500 John R Levine <[EMAIL PROTECTED]> wrote: Or consider S/MIME. S/MIME applications have a cert list similar to the one in a web browser, so they also have the problem of dividing the world into haves who can afford a cert with a signature from someo

Re: Troubles with UTF-8

On Dec 28, 2005, at 7:16 AM, Julian Reschke wrote: The 'illegal syntax' is not yet an RFC but is in draft-ietf- netconf-ssh-05.txt which says "As the previous example illustrates, a special character sequence, ]]>]]>, MUST be sent by both the client and the server after each XML Wh

Re: Alternative formats for IDs

John, I've still got some misgivings about PDF because one of my requirements is to be able to extract things from documents and mark them up. Good question. I do think that we need the ability to extract material for various purposes, including o Comparisons (rfcdiff etc) o Bis-constructio

RE: Consensus based on reading tea leaves (was: Re: Alternative formatsfor IDs)

> I can't imagine that ever encouraging the IESG to decide > that they know what IETF consensus "really" is, > while disregarding public comment, > is ever going to be a good thing to do. How did you read that into what we said? We never said that IETF consensus should not be gauged. Quite t

Re: SIQ, SPF, BATV, etc.

Douglas Otis wrote: > The "exists" scheme does not seem to make any sense either, AFAIK it's a way to check if mail claiming to be from [EMAIL PROTECTED] was originally sent from [EMAIL PROTECTED] - if that's correct nothing is wrong with the idea so far, domain y only needs a name server returni

Re: bozoproofing the net, was The Value of Reputation

> Indeed. And, along the lines of my response to John, and to > Dave's request to be specific, that sort of analysis and > description is _precisely_ what I believe should be required to > be written into text, ... The more I think about this, the less sense it makes. DKIM is not the first misus

Re: bozoproofing the net, was The Value of Reputation

If such agreement cannot be reached, then I think DKIM has much more serious problems about applicability and the definition of the problems being solved than whether or not this is required. John, Unfortunately what you appear to be saying is that you are certain of serious problems, and

Re: SIQ, SPF, BATV, etc.

On Dec 31, 2005, at 10:31 PM, Frank Ellermann wrote: Douglas Otis wrote: The BATV draft seems to be a good start. Perhaps it can be further simplified. Could this satisfy both camps? Which both camps, SES vs. BATV, STD 10 + SPF vs. STD 3 + 2821, or something else ? For the former I'm lo

Re: bozoproofing the net, was The Value of Reputation

--On Sunday, 01 January, 2006 15:49 -0800 Douglas Otis <[EMAIL PROTECTED]> wrote: >... > The risks related to interoperability will more likely result > from assuming authorization authenticates the source. This > authorization strategy may benefit larger domains, but will > be corrosive to g

Re: bozoproofing the net, was The Value of Reputation

On Jan 1, 2006, at 8:35 AM, John C Klensin wrote: --On Sunday, 01 January, 2006 04:35 + John Levine <[EMAIL PROTECTED]> wrote: I hope the message here is not that we should restrict ourselves to developing technology that is idiot-proof, since a sufficiently determined idiot, of which

Re: IETF Last Call: draft-salowey-tls-ticket-06.txt

> >>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

RE: Alternative formats for IDs

--On Sunday, 01 January, 2006 12:48 -0800 "william(at)elan.net" <[EMAIL PROTECTED]> wrote: >... > BTW - PDF also still rather "fluid" format with multiple > versions and not always clear if PDF you create could be read > by all readers in the same way you intended. So if PDF is as > format, then e

RE: Alternative formats for IDs

On Sun, 1 Jan 2006, Yaakov Stein wrote: 2: Folks who can't read MS Word documents are also irrelevant. It's the "most 'standard' document exchange language on the Internet". (Actually all its versions are from the people who invented the Internet, please don't forget to submit an IPR n

Re: IETF Last Call: draft-salowey-tls-ticket-06.txt

Bernard Aboba <[EMAIL PROTECTED]> writes: >> In the extreme case (client gets different server every time, and none >> of the servers can understand tickets generated by other servers), it >> will degrade to normal TLS (full handshake done every time). > >>From what I can see, the Ticket structur

Re: bozoproofing the net, was The Value of Reputation

John K., et al, Feliz año nuevo; Selamat tahun baru. I do believe that it is not desirable to create standards that would give a gift of either technology or justification to those who would use them to fragment the network. I believe it is especially I suspect we will not find anyone in

Re: bozoproofing the net, was The Value of Reputation

> Think of it as an explicit "interoperability considerations" section to > supplement the usual "security considerations" one. That seems reasonable, so long as someone steps forward to write it. > I note that we have never standardized a magic bullet in the anti-spam > area. I believe that to

Re: bozoproofing the net, was The Value of Reputation

--On Sunday, 01 January, 2006 04:35 + John Levine <[EMAIL PROTECTED]> wrote: > I hope the message here is not that we should restrict > ourselves to developing technology that is idiot-proof, since > a sufficiently determined idiot, of which there are many, will > do idiotic things with any

Consensus based on reading tea leaves (was: Re: Alternative formats for IDs)

I do appreciate the authors writing a draft, as opposed to participants who make a usual vague process change suggestion on ietf@ietf.org and generate confused discussion that results from no two commenters having the same understanding of the proposed process change... HOWEVER. I can't imagi

Re: Alternative formats for IDs

Hi Yaakov, on 2006-01-01 06:36 Yaakov Stein said the following: > Happy new year to everyone. > > I would like to call your attention to a new ID > http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt > . > > This

Re: Alternative formats for IDs

Yaakov Stein wrote: > We suggested taking a show of hands amongst the thousands > who read IDs and RFC, and not only among the five or so very > vocal people who respond to emails on the IETF general > list within 5 minutes (even on January first) . I read it the day before yesterday, so that "5

Re: Alternative formats for IDs

Yaakov Stein wrote: ... We did get quite a lot of off-list support and frequently the subject line was copied from messages on the list. This makes it confusing as to what was said in public, and what was seen only by us. > ... I see that argument from time to time, and frankly I don't buy it

Re: Alternative formats for IDs

Frank Ellermann wrote: 2: Folks who can't read MS Word documents are also irrelevant. It's the "most 'standard' document exchange language on the Internet". (Actually all its versions are from the people who invented the Internet, please don't forget to submit an IPR note). Yes, t

Re: Alternative formats for IDs

I am in favor of enhancing graphics formats that we allow for normative versions of our drafts and RFCs. (Note that this is already allowed for non-normative things, such as a graphic state machine descriptions in a .pdf when .txt has a state table.) However, I would like to limit a new graphic

RE: Alternative formats for IDs

Yes, it introduces at least five surprising and new concepts: 1: "rough consensus" is determined by taking 1000 default YES- opinions, and then consider up to 20 explicit objections as irrelevant. [YJS] Humorous, but not what we said. We suggested taking a show of hands amongst the thousa