Interestingly, on the .1X SSID, I get 14 % loss and delays up to 8000
ms (!).
The open SSID is about 0 % loss (didn't wait for the first loss long
enough) and 60 ms on average.
Just a data point why I'm back in the open net.
Gruesse, Carsten
___
Ietf m
On Oct 21 2004, at 17:49 Uhr, Tim Bray wrote:
If the IETF wants to ignore history and build an Internet where that
doesn't hold, feel free, but it's not a very interesting kind of
place.
This has been rehashed a lot, but there are two little facts left out
from the current repetition of the disc
On Nov 06 2004, at 21:27 Uhr, Stephane H. Maes wrote:
disfranchised
If you really have to continue your crusade on the IETF list, can you
at least stop using this word (assuming you mean disenfranchised)?
There is no voting in the IETF, so you can't be deprived of any voting
right.
Gruesse, Cars
On Nov 07 2004, at 07:36 Uhr, Adrian Farrel wrote:
Disfrachise is a perfectly good word. I believe it means exactly what
Stephane intended it
to mean...
Probably.
That's why I spoke up.
"To deprive of a franchise or chartered right; to dispossess of the
rights of a citizen,
or of a particular pri
On Nov 10 2004, at 14:18 Uhr, JORDI PALET MARTINEZ wrote:
By the way, the press should take note about Airespace marketing versus
reality. I hope this company can be honest an make a public correction
on
that, otherwise customers should not trust them anymore.
Oh, come on, give them some slack.
Co
On Nov 18 2004, at 10:26 Uhr, JFC (Jefsey) Morfin wrote:
if there is no hassle like [...] paying for this and that
I'm a bit afraid there are players in this game that won't let us
completely eliminate that hassle.
Obviously, a situation where a /48 can only be obtained at business
rates leads u
On Dec 16 2004, at 12:46 Uhr, Eliot Lear wrote:
RFC1618 PPP over ISDN
We had a short discussion about this in pppext.
The gist was: The document is pretty bad (partly because things were
murky in 1994, but also because it was written by Martians that had no
space ship to take them to the IS
On Dec 16 2004, at 14:02 Uhr, Margaret Wasserman wrote:
RFC0885 Telnet end of record option
This option was, at least at one time, used for telnet clients that
connected to IBM mainframes... It was used to indicate the end of a
3270 datastream.
... and 5250 (RFC2877).
Note that there was a
Why do we care if there are still implementations that are based on
these documents in use?
The important question is whether there are going to be new or revised
implementations based on these documents.
A new implementation for tn5250 is about as likely as a new
implementation for NTP.
Stand
On Dec 16 2004, at 18:13 Uhr, Harald Tveit Alvestrand wrote:
please read draft-ietf-newtrk-cruft-00.txt, in particular section 3.2,
Ah good, I did.
o Usage. A standard that is widely used should probably be left
alone (better it should be advanced, but that is beyond the scope
o
I'm seeing a lot of confusion in this thread.
In the past, we have had real problems with wireless.
802.11 implementations are too easy to confuse by stations with random
settings, we have seen our share of stations that switched to
ad-hoc/IBSS mode when there were connection problems, drawing ot
On Mar 14 2005, at 14:07 Uhr, Keith Moore wrote:
we used to get a lot more work done when we used our meetings
primarily for discussion rather than scheduling presentations for most
or all of the meeting time.
Yes. WG chairs planning WG meetings, take note.
But then, one difference is that a lot
Lucy,
congratulations, but "First intercontinental videoconference from the
air"; hmm.
Some of us have done this before (using iChat, no less).
Gruesse, Carsten
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
On Mar 16 2005, at 19:33 Uhr, Dave Crocker wrote:
Cheap and easy travel and lodging, for diverse participation
I wouldn't want to completely rule out the US that quickly...
Gruesse, Carsten (who has had to stand in for a colleague with a Sri
Lanka passport on 2 out of 3 IETFs recently)
__
On Mar 17 2005, at 19:40 Uhr, Jeffrey Hutzelman wrote:
they could have broken out the emergency AP's and provided worse
coverage to fewer areas than we had last week. It would have been
better than nothing, but it would _not_ have been better than what we
got.
Actually, for those of us who had
On Mar 21 2005, at 17:53 Uhr, Baker Fred wrote:
worries about pick-pockets, the number of airports one has to go
through to get to them, likelihood of being able to get a meal on
schedule (which is a question of customs - many places in Europe a
restaurant assumes that you don't enter the restau
On Apr 02 2005, at 15:35 Uhr, Sam Hartman wrote:
Similarly the
rest of the world would like to show that we should have the meetings
closer to them.
You are making an assumption about the motives of the people that point
out the continuing decline of suitability of the US as a meeting place
for a
Now that the two previous main concerns about the Paris IETF are
under control (nobody has died from the heat yet and the pocket loss
rate is at the expected levels), I have a real problem that is
actually hindering the work:
Coach class.
Opening the laptop in the seat arrangement provided
On Aug 03 2005, at 12:38 Uhr, Joerg Ott wrote:
we should consider to organize out future meetings in a
similar fashion.
Yes, yes, yes!
Another really useful feature here in Paris were the tables for sit-
down breakfast.
Result: Productive breakfast meetings.
Gruesse, Carsten
On Nov 09 2005, at 06:27 Uhr, John C Klensin wrote:
I've only occasionally found the network stable enough
At the danger of spilling the beans:
Once I switched may laptop to .11a, the network has been rock-solid.
(I ran a ping yesterday, and it did not lose *a single packet* on the
wireless
On Nov 10 2005, at 14:34 Uhr, Gray, Eric wrote:
people wanting to have a private ad hoc network ought
to look at the frequencies being used by local base-stations
so that their signals do not interfere with people using the
"infrastructure" mode.
Paradoxically, they have to use *the same* freq
Guidelines would be nice, but wouldn't help here:
The evidence seems to identify systems as the culprits with operating
systems that have not been upgraded in the last half-decade.
Those won't benefit from new information.
(I don't want to start discussion about the economic realities that
On Nov 15 2005, at 18:47 Uhr, Juergen Schoenwaelder wrote:
Every little open source software project uses version control systems
these days. The IETF does not.
Many WGs, of course, do, in scattered places, using random identity/
authentication schemes, depending on individuals for hosting th
On Nov 15 2005, at 21:48 Uhr, JORDI PALET MARTINEZ wrote:
I don't think anyone participating in the
session will modify its own slides during the session.
You cannot have been to IETFs much, have you? :-)
People modify their slides even *during their presentation* all the
time, certainly als
>
> just a press release
Slightly more than a press release:
http://www.networkworld.com/cgi-bin/mailto/x.cgi?pagetosend=/export/home/httpd/htdocs/news/2008/031208-ipv6-ietf.html&pagename=/news/2008/031208-ipv6-ietf.html&pageurl=http://www.networkworld.com/news/2008/031208-ipv6-ietf.html&site=la
On Aug 01 2008, at 08:53, Ole Jacobsen wrote:
problem
The problem is that the spin of the article is that NATs are being
added to IPv6 itself (which is a misleading statement when taken at
face value, actually surprising, hence perceived as sensational), when
in reality they are being ad
Ten years ago, on August 10, 1998, the IESG announced the protocol
action to make a set of Internet-Drafts into Draft Standards, now RFC
2460 to RFC 2463. For many of us this marked the end of the gestation
and the start of what has become a long, long deployment process.
In these ten year
On Dec 1, 2008, at 15:43 , <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> wrote:
Process control doesn't need IP at all at the
edge of their network.
This is a side-track, but:
Some people in the IETF, as well as in the industry, might disagree...
Watch out for the next billion nodes on the Intern
http://www.fsf.org/news/reoppose-tls-authz-standard
While I have a lot of sympathy for the cause, I have very little
sympathy for the methods.
Rendering a mailing list that might be useful for actually resolving
the issue inoperative by a "campaign" is idiotic.
Somebody from I* (the IETF chai
On Feb 10, 2009, at 15:46, Michael Richardson wrote:
The IETF should be *thrilled* that so many people care!
In a world with unlimited time, yes. In the real world, polluting the
discourse by hundreds of more or less unconsidered knee-jerk reactions
just makes sure that *I* can't take pa
airline miles
Don't know, but related trivia:
On the IETF pain scale, I have crossed 230.5 timezones (and, apart
from Dallas, the same number back) on the way to IETF meetings so
far, which would be equivalent to going around the earth nearly 20
times just for IETF meetings (not countint I
On Mar 22 2006, at 13:00, Tim Chown wrote:
non-US citizen
Sure, get a credit card from a US bank with a US billing address.
No comment (to forestall incessant ranting about *DELETED* 20th
century policies).
Gruesse, Carsten
___
Ietf mailing li
On Jun 05 2006, at 23:43 , Iljitsch van Beijnum wrote:
What is considered best practice for encoding data in protocols
within the IETF's purview?
The best practice is to choose an encoding that is appropriate for
the protocol being designed.
(There is no single answer.)
Maybe you can be m
On Jun 06 2006, at 20:55 , Hallam-Baker, Phillip wrote:
There
seem to be a lot of ad-hoc
ASN.1 decoders out there that people have written as part of
some other protocol, instead of using an off-the-shelf
compiler/encoder/decoder;
That's because most of the off the shelf compiler/encoders have
A little post script to this discussion: I wrote a few small test
programs in C to evaluate the performance of reading integers from
a text file using versus doing the same with direct read()
s from a binary file. The difference is between two and three
orders of magnitude. See http://ablog
Well, http://pingsta.com/terms.php was written by a lawyer (so I
can't claim to understand it), but the gist is that you give Pingsta
the rights to everything you put in there but are not allowed to make
anything in there available in the open ("derivative works").
They clearly haven't arri
On Jul 30 2007, at 16:46, John C Klensin wrote:
meetings held in tourist
destinations
Is that *really* still an issue for anyone?
It's not that the IETF is considered a boondoggle org (like some
other standards organizations I have known).
Places like Mallorca in Spain (or Orlando in Flori
On Aug 08 2007, at 10:16, Arnt Gulbrandsen wrote:
If example.com wants to use them, example.com will have to
upgrade its own computers and routers to a version which supports this
new class E. Nontrivial, rather expensive, but doable.
Cheaper to use IPv6, then.
Non-starter, I'd say.
Gruesse,
One more point: An argument does not become stronger by being repeated
more often.
Of the 175 senders to this list last month, 20 of us contributed more
than half the list traffic. If we have made our position clear, the
argument is, I think, stronger if it is not repeated - and silence
allows
(I've seen "moderator" used in 2 ways - the "summarize and state
consensus" role Carsten mentions below, and the "sanction
inappropriate behaviour" role that is commonly used with "mailing list
moderator" - these roles don't have to be done by the same person)
Ah, words.
Moderator in the se
The biggest questions I have are:
- where to put this bit?
Right now, the *only* way an L2 with varied service levels can derive
what service levels to use for best-effort traffic is to perform a
layer violation. Continuing this tradition, the bit would be:
less_than_perfect_L2_error_detection
How would an app know to set this bit? The problem is that different
L2s will have different likelihoods of corruption; you may decide that
it's safe to set the bit on Ethernet, but not on 802.11*.
Aah, there's the confusion. The apps we have in mind would think that
it is pointless (but harmle
- Some pages claim "not compatible with your US handset" -- i.e. no
CDMA roaming
Ole,
I remember from the last time I worked on Korean CDMA systems they had
a different frequency (1700 MHz?).
Gruesse, Carsten
As for those people who run around with their cards in ad hoc mode,
yes,
especially here, they should know better.
One problem may be those "helpful" features where the OS is switching
to ad-hoc when there is no base station to be seen. In Mac OS X 10.2,
you can disable that (switch off "Allow
it turned out that when I replaced my Linksys 802.11b with
a brand new Motorola 802.11g the problem went away; there is a Radio
Shark on the third floor of City Center that sells them for $70.
Similarly, when I put a $70 Linksys WPC54G (directly supported by Mac
OS X 10.2.8) into my Powerbook to o
Nice discussion of the problem space.
(1) At the time, there was no obvious compression algorithm (given IPR
encumbrances, etc.)
Let me quickly add that RFC3320 was designed to solve that specific
problem (and the resulting deployment economy/interoperability
problems). The RFC was developed i
> ... we should prefer technology which will be available
> royalty-free, but that's not current policy
Whose policy?
Some WGs have a policy (or are actually chartered) to develop deployable
protocols. Where a legal issue would make a protocol non-deployable, we have to
look elsewhere. (Of
> I think the most effective thing would be to send a strong signal of some
> kind: "If you patent technologies and give non-RF licenses, _do not expect
> the technology be supported in IETF at all_".
The problem is that there are enough companies out there that don't care.
There are some area
Somebody is running a number of ad-hoc nodes (or one chameleon-style node) in
the 802.11b airspace of the IETF meeting. This is bad enough as it is not
coordinated with the site's frequency plan. It is even worse when at least one
of the nodes uses the SSID "IETF", which causes all Macs (and
Japan can use all 14 WiFi channels (World/ETSI can use 13, US/FCC 11).
The IETF network was restricted to the US 11 channels, obviously so that users
of US cards would not be left cold.
On Monday, and for some time on Wednesday, there were problems with overlapping
channels. In WiFi, channel b
http://www.ietf.org/internet-drafts/draft-ymbk-termroom-op-07.txt
... which contains surprisingly little information about radio network
planning.
This has been wrong on most IETF Monday mornings, and tends to get
fixed slowly during the week.
How are the lessons learned relayed to the next tea
On Oct 24, 2012, at 06:20, David Sheets wrote:
> WHATWGRL
Hey, call them EARLs. Error-tolerant web-Address Repairing Labels or whatever.
(Just not URLs, that term is already taken in the Web.)
Grüße, Carsten
On Oct 25, 2012, at 16:37, "Adrian Farrel" wrote:
> retro-active
I don't get how that is relevant.
This is for the case the seat is still vacant when the new process comes into
force.
I'm still amazed at the number of messages the resolution of this issue has
generated.
There is complete cons
On Oct 25, 2012, at 20:52, Doug Barton wrote:
> On 10/25/2012 9:57 AM, Carsten Bormann wrote:
>> On Oct 25, 2012, at 16:37, "Adrian Farrel" wrote:
>>
>>>> retro-active
>> I don't get how that is relevant.
>> This is for the case the se
On Oct 25, 2012, at 21:20, Doug Barton wrote:
> _punitive_
Again, you are confused.
This action is not about punishing an individual, and I would be violently
opposed to it if it were.
This is my last message on this.
I'm repulsed by the idea of discussing this under this premise.
Grüße, Ca
On Nov 12, 2012, at 19:09, Dave Crocker wrote:
> Some people believe that the presence of an IETF meeting serves as a kind of
> recruitment marketing to a region, for IETF participation. Beyond the
> single-meeting boost in 'local' attendance, I believe we have no data
> confirming any on-goin
On Nov 14, 2012, at 20:59, Dave Crocker wrote:
> On 11/14/2012 9:34 AM, Carsten Bormann wrote:
>> (Another aspect beyond capturing regular attendees, of course, is
>> gaining local mindshare and relevance.
>
> I believe I understand the concepts that are meant by such lang
On Nov 15, 2012, at 17:04, Dave Crocker wrote:
> I'm saying that your point lacks an empirical basis
Yes.
I'm not even arguing that the IETF spend effort on obtaining that empirical
basis (hint: there is probably a great PhD thesis in organizational marketing
waiting to be written).
My hypoth
On Dec 3, 2012, at 15:25, Barry Leiba wrote:
> But code that's written as part of a rote process, just to achieve
> another check-box on the shepherd writeup and justify special handling
> is not likely to provide any of those benefits.
+1.
As somebody who tends to think about security implicat
For those who wonder what all the fuzz in this thread is about, let me try to
explain this with some different terminology, exposing what kind of intuition
these widely diverging value judgements might derive from.
In programming, there are two camps: static typers and dynamic typers. Static
t
On Jan 22, 2013, at 08:05, Melinda Shore wrote:
> why you're specifically requesting implementations in C
I think his argument is that the spec author should be punished for each piece
of fluff in the spec.
A sentiment that I can relate to.
Having to write C code probably does qualify as the a
On Jan 23, 2013, at 20:56, John C Klensin wrote:
> But having CR as an unambiguous "return to first
> character position on line" was important for overstriking
> (especially underlining) on a number of devices including line
> printers as well as TTY equipment.
But John, on a TTY, you have to s
On Jan 24, 2013, at 04:41, wor...@ariadne.com (Dale R. Worley) wrote:
>> From: Carsten Bormann
>>
>> I think in protocol evolution (as well as computer system evolution
>> in general) we are missing triggers to get rid of vestigial
>> features.
>
>
This is my last comment on the CRLF issue, which I just used as the
(for me) obvious example for what I was trying to say.
On Jan 24, 2013, at 02:20, John C Klensin wrote:
> Oh, my. This is getting to be interesting. I had no direct
> interaction with or insight into the ASA (later ANSI) commi
On Feb 25, 2013, at 17:33, jari.ar...@piuha.net wrote:
> A tools-login required for posting comments?
In a ~ 20-year IETFer, it evokes a bit of a smirk to see the IETF now starting
to define its social media strategy...
The answer to the question depends on whether you want to engage IETFers on
On Feb 27, 2013, at 19:18, ned+i...@mauve.mrochek.com wrote:
> routing around obstacles
It turns out for most people the easiest route around is submitting in time.
That is actually what counts here: how does the rule influence the behavior of
people.
Chair hat: WORKSFORME. (And, if I could d
On Mar 5, 2013, at 18:58, Bob Braden wrote:
> Which is why we learned 30 years ago that building a transport protocol at
> the application layer is generally a Bad Idea. Why do the same bad ideas keep
> being reinvented?
Because we don't have a good selection of transport protocols at the tran
On Mar 7, 2013, at 07:55, Toerless Eckert wrote:
> Really ? You don't think a good AD should primarily look for factual evidence
> (lab, simulation, interop, ..) results produced by others to judge whether
> sufficient work was done to proof that the known entry critera are met
> (like no conges
ively suspended for six weeks a year.
Grüße, Carsten
PS.: (If that sounds like I'm contradicting myself that's only because we
haven't found the right solution yet.)
On Feb 27, 2013, at 19:49, Carsten Bormann wrote:
> On Feb 27, 2013, at 19:18, ned+i...@mauve.mrochek.com wrot
On Mar 12, 2013, at 17:03, Dean Willis wrote:
> a wiki-like inline markup language
Well, actually it uses markdown, which seems to have a rather large penetration
when it comes to writing-oriented markup.
If you want to use markdown for collaborating on RFC-style documents, there are
tools li
I wouldn't mind replacing my blue dot with an indication *what* WG I chair, and
in which area that is.
Might be a bit more logistics when chairs change, but nothing that can't be
solved with a DYMO labelmaker.
Grüße, Carsten
On Mar 19, 2013, at 13:22, Michael Richardson wrote:
> Instead of getting a new badge every meeting, maybe we should just get
> an IETF86 dot on a badge we keep from meeting to meeting.
I want my badge on a shiny embossed metal plate with the words "protocol
police" on it.
Where do I have to ap
> Further, the IETF should acknowledge that the contents of Acknowledgments
> sections varies widely between RFCs. Some are fairly complete, some are
> fairly vague and incomplete, and some are between.
Bingo. It is up to the sole discretion of the document authors what they want
to list in th
On Mar 25, 2013, at 15:38, Paul Hoffman wrote:
>> The contents of the Acknowledgment section is about as much subject to WG
>> consensus as the authors' street addresses.
>
> Disagree. WG documents are WG documents. If the author/editor doesn't want to
> do what the WG consensus is about the d
Hi Shoichi,
On Mar 19, 2013, at 01:55, Shoichi Sakane wrote:
> And, the length of URI is likely to be bigger than the MTU.
>
> Do you assume a use case in which the total length of options is going
> to be greater than the MTU ?
CoAP has been designed for constrained devices, and networks buil
On Mar 27, 2013, at 22:26, David Kessens wrote:
> Recently, there has been a lot of discussion in the IETF about diversity.
Is it just me or is the liaison manager for the politically tempestuous ITU-T
relationship really about the worst possible position to exercise this point on?
Choose your
Jari,
this is great news. A design team approach may be able to collect
information and generate ideas and actionable points in a way that
works much better than ranting on the IETF list.
The most important insight is that diversity is not a "problem" that
can be "fixed" by some set of measures,
Michael,
thank you for this thoughtful and extensive review.
We have turned nine of the items below into eight tickets, #287 to
#294 (see in-line references below), that will be processed along with
the other IETF last-call tickets and turned into
draft-ietf-core-coap-15 in the next few days.
Be
On Apr 18, 2013, at 17:17, "Dan Harkins" wrote:
> Why is this a problem?
I think you are more likely to ask this question if you think that if it is a
"problem", then we *have* to "solve" it, e.g. by shooting enough of the white
male people in the IETF that the numbers balance.
It is not that
On May 1, 2013, at 18:33, Michael Richardson wrote:
> we need to create a new category of document which
> amounts to "fully baked ID"
Yes. (I'm not sure it's a category, it might just be a stage.)
There is a stage in the development of a protocol where I no longer want to
hear "it's just a d
On May 1, 2013, at 20:11, Michael Richardson wrote:
> It's what PS *ought* to have been, and what "RFC"s were prior to
> 1990 or so.
One problem is certainly the cognitive barrier imposed by the RFC process.
-- RFCs never change, so you want to get them right;
-- there is a two-month editorial p
On May 2, 2013, at 07:21, "Eggert, Lars" wrote:
> Yeah, all kinds of issues, but if we created a new thing here in between WGLC
> and PS, the broader industry would never understand.
That is a matter of naming and marketing ("candidate RFC"?).
The "this is baked, go and implement it" signal to
On May 3, 2013, at 01:13, Peter Saint-Andre wrote:
> source control
I don't think it has been emphasized enough how important that is from a
document quality perspective.
More importantly for this discussion, it also somewhat mitigates the document
editor as a choking point.
People who aren'
Wow, that's real science at work...
Sorting by the relevant column (I don't own a private jet):
> LHR 249:44 // London
> FRA 255:22 // Frankfurt
> SFO 282:04 // San Francisco
> FCO 283:04 // Rome
> SVO 287:14 // Moscow
> ATL 297:28 // Atlanta
> BOS 297:38 // Boston
> NRT 314:38 //
On May 31, 2013, at 16:53, Spencer Dawkins
wrote:
> co-authoring with folks outside their region.
Very good point.
Significant advantage comes from any kind of co-authoring with someone who is
able to bring another perspective. By region, by academic/commercial interest,
by vendor/operator
On Jun 11, 2013, at 13:17, wrote:
> We have to know, not that you have read the document, but that you have
> -understood- it.
Process experiment:
end all Internet-Drafts with a multiple-choice test.
Grüße, Carsten
Well, one of the BOFs is for 6Lo, which is meant to replace a WG (6LoWPAN) that
is closing.
So make that 14 potential new WGs, but it is still a large number indeed.
(Actually, not all BOF descriptions are entirely explicit about the desire to
have a new WG as an outcome...)
Grüße, Carsten
On Mar 29, 2010, at 00:56, Iljitsch van Beijnum wrote:
>> From Frankfurt it is (of course) faster to take a high speed train, and from
>> Paris it's the only option. The downside of high speed trains is that you
>> can't just hop on like on a regular train, you need to book or reserve a
>> seat
On Mar 29, 2010, at 12:05, Iljitsch van Beijnum wrote:
> suitable for travel to Maastricht, such as Cologne/Köln
More useful from, say, the US (often surprisingly inexpensive), and quite
reasonably connected to Maastricht: Duesseldorf (DUS).
I'd probably look for BRU, DUS, AMS, FRA (in that orde
On Jun 23, 2010, at 15:06, Martin Rex wrote:
> optimizing for their own interest alone
I don't know about you, but when I set up a server, I have a strong interest
that my clients get their data fast.
So whatever it takes to do that, is in my interest.
BTW, initial analyses of iOS 4 (iPhone OS)
On Jun 25, 2010, at 09:56, Brian E Carpenter wrote:
> trying v6 for a couple of seconds before trying v4 in parallel
I don't think this is realistic for applications like the Web, where people are
now creating Youtube-Spots with high-speed cameras that show, in slow-motion, a
potato cannon fire
On Jun 25, 2010, at 16:16, Brian E Carpenter wrote:
> initial phase of contact with a server
To get the front page of the New York Times (http://www,nytimes.com), "a
server" a couple of minutes ago meant
http://admin.brightcove.com/
http://b.scorecardresearch.com/
http://creativeby1.unicast.com
On Jul 30, 2010, at 14:54, Jari Arkko wrote:
> people consistently referring to the meetings as "BOFs",
The fix is to call the formal working group formation planning meetings
"working group formation planning meetings", not to stop calling the literal
BoF meetings "BoFs". A lot of conference
OK Jordi, you fell victim to a marketing site.
I've got some news for you: Not every site on the Web has accurate information.
Let me explain how that works. Something new comes along (say, a new train
service) and marketing material (a web site) is generated. Some budget is set
aside. The we
> But while we're at the topic of *running* xml2rfc: I always advise people to
> run it locally;
One problem is that the "default" way of doing references in RFC 2629 XML
appears to perform an online fetch of the reference information for each build,
with no caching whatsoever. If you do have
> Yes, that's why I always recommend not to use that style.
But hardwiring the references in the XML leads to manual updating (and
forgetting that).
Having a tool for that is useful here (which is why kramdown-rfc2629 does this).
>> BTW, if you are on a Mac, get one of the package managers "macp
On Jan 27, 2011, at 09:52, Lars Eggert wrote:
>> all new protocols should
>> be security-capable
Sure.
How is this relevant?
In some protocols, there is value to use them without communication security
(think TLS) for some applications, and with communication security for others.
We used to d
On Feb 15, 2011, at 21:46, Stuart Cheshire wrote:
(readable E-Mail)
How did you manage to get Apple Mail to properly use RFC 3676, i.e.
; Format="flowed"; DelSp="yes"
on the Content-Type? Apple broke that in 10.6, IIRC.
(Not that solving this problem on the sender side would solve it
On Jun 20, 2011, at 15:31, Cullen Jennings wrote:
> This is all a sort of confusing point of many IETF documents and not unique
> to this one. I think the important points is that for many IETF documents,
> the people listed on the front page are not the authors. Typically the list
> of authors
On Aug 9, 2011, at 20:30, Nathaniel Borenstein wrote:
> We worry too little about the opportunity cost of the passage of time, so we
> fight time-consuming battles. We should instead be trying to build an
> optimal pipeline of incremental progress in a generally positive direction,
> acknowled
1 - 100 of 160 matches
Mail list logo
