This draft's premise is interesting, but the implementation leaves to be
desired. That is, I like the idea of fragment identifiers for CSV, but
row/column/cell-based selection doesn't address my need.
My need is based on the CSV files generated from IANA registries. Here's
one:
Le 2013-10-11 17:52, Barry Leiba a écrit :
This is an Independent stream document, and the IETF doesn't have
change control of the document.
The authors can certainly accept your comments at their discretion.
But this last call isn't for comments on the *document*. It's only to
assess
Le 2013-07-22 13:55, Philipp Kewisch a écrit :
-- 3.2.1.1:
What happens for future versions of vCard? Do you simply use the new version
number, or would we need a new version of this spec? I suspect the latter.
If true, it might be worth mentioning that, or somewhere early in the draft
Le 2013-07-11 02:04, Hui Deng a écrit :
We submitted two drafts to help people here to correctly call chinese
people names:
http://tools.ietf.org/html/draft-deng-call-chinese-names-00
http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00
Very cool! Thanks for writing this!
I have
Le 2013-07-11 16:22, Cyrus Daboo a écrit :
So, from a technical standpoint, it seems better to always represent
user names using components (last, first, middle)? vCard does have an
N property where individual components of a name can be broken out.
I'm nowhere near an expert on this topic,
Le 2013-07-11 17:44, John C KLENSIN a écrit :
Hence the common practise in some academic circles of giving
the family name in all capitals, to show which it is. So
whether you see Junichiro KOIZUMI or KOIZUMI Junichiro, you
know what you're seeing.
Not just in academic circles but in some
Le 2012-11-05 19:10, Carlos M. martinez a écrit :
Other than the CGN-mib we discussed today in sunset4, I wondered whether
is there ongoing work on this topic.
What do you mean exactly? Because there is nothing IPv6-specific in the
CGN MIB (or NAT MIB), it's all address-family agnostic...
Le 2012-09-26 05:31, Stephen Farrell a écrit :
stuff that's utterly incompressible
Oops - let's see if the phone spell checker gets incomprehensible right this
time:-)
I understood incompressible as equivalent to pure random noise, and
it made sense! :)
Simon
--
DTN made easy, lean, and
Le 2012-09-10 06:46, Dearlove, Christopher (UK) a écrit :
If someone wants to provide guidance on how to do a least bad job
with Outlook, that will be gratefully received.
Found this using the Google:
http://home.in.tum.de/~jain/software/outlook-quotefix/
No idea if it's any good as I don't
Le 2012-09-05 09:12, Michael Richardson {quigon} a écrit :
Let me suggest that at the IETF, where the mailing list is king, you can't join
the Elite if you can't quote email properly.
Maybe we should *state* this.
Maybe I'm also concerned because many in the former elite have moved to Apple
Le 2012-09-07 14:36, Scott Brim a écrit :
Maybe I'm also concerned because many in the former elite have
moved to Apple Mail, and it seems that it is bug compatible with
Outlook in it's assumption that format=flowed is the default, an act
which destroys email quoting, and therefore discussion.
Le 2012-09-07 15:15, Melinda Shore a écrit :
On 9/7/12 10:53 AM, Simon Perreault wrote:
Thunderbird is correct by default AFAIK.
Unfortunately not on Mac OS. It's become automatic for me to
hit command-R when replying, but that doesn't solve the basic
problem.
That's what we've been saying
Le 2012-08-08 12:34, Geoff Mulligan a écrit :
I also would vote to return to Minneapolis again and again even permanently.
Does nobody care about going to new places so that new people are
exposed to the IETF and may start getting involved?
We've seen this positive effect many times when we
Le 2012-07-24 03:06, Stephane Bortzmeyer a écrit :
And since when Microsoft software is required for IETF work?
Even though I replied to the survey, this also irritated me. And I sense
a trend here. It seems that the number of non-plain-text files coming
from IAB has been increasing.
Le 2012-07-19 14:20, David Harrington a écrit :
The IETF could mandate a specific protocol to try to ensure
interoperability, but doing this takes the decision out of the
responsibility of the deployer to choose the best solution for the
deployment environment, and out of the responsibility of
On 07/10/2012 10:43 PM, Tina TSOU wrote:
First, the port numbers to be allocated to CPE. Excluding Well known
port numbers should be mentioned.
As draft editor, I would ask for a justification. I can't add a
requirement without a justification.
Moreover if port numbers are allocated
to
On 07/03/2012 08:24 AM, Alexey Melnikov wrote:
I found the justification for REQ-6 hard to read/understand. Why does
access to
servers being on the internal network need to go through CGN at all?
Here's the thing: the server is not on the internal network. It's on the
external network, but it
(adding p...@ietf.org to the recipients list...)
Sam,
Thanks for the review, comments inline...
On 07/10/2012 02:16 PM, Sam Hartman wrote:
Requirement 9 requires a Port Control Protocol (PCP) server. I think we
need to say somewhat more about that in order for PCP to be secure on a
CGN. In
On 07/10/2012 04:03 PM, Sam Hartman wrote:
and MUST NOT support the third-party option.
Simon I think pcp-base-26 added restrictions to THIRD_PARTY so that it
could
Simon be used in CGN scenarios. If that is right, wouldn't it then make
Simon sense to allow THIRD_PARTY on
On 2012-07-09 11:03, George, Wes wrote:
While the NAT specified by this
document itself may only act on IPv4 traffic, as you note above it's
not limited to just NAT444 or even an IPv4-only *network*. The
recommendations in this doc will work for an IPv4 NAT associated with
DSLite just as easily
On 07/03/12 05:51, Eggert, Lars wrote:
On Jul 3, 2012, at 14:24, Alexey Melnikov wrote:
I found it is to be odd to have a requirements document as a BCP, but I am sure
you can sort the right status out with IESG.
+1
I fail to see why Informational wouldn't be the better status.
I don't
Wes,
Here's my take on this...
CGN as defined in this document does not only include NAT444. It is more
generic than that: it really means multi-user NAT. Dave Thaler came up
with the example use case of the NAT in a wifi hotspot. It's just NAT44,
but it still fits with the draft's
On 2012-05-31 04:58, Stephen Farrell wrote:
I'm with Brian and Yoav on this. I don't see a need
to change here. And I do think we might lose something
if we become too PC. If a bunch of non-native speakers
did say yes, I found that made the document less
useful then I'd be more convinced that
On 2012-05-25 18:30, Cullen Jennings wrote:
WIll the IPFIX and MIB work also be usable by v4 to v4 NATs?
Speaking as an author of draft-ietf-behave-nat-mib, our intent is to
support all kinds of NAT, but it isn't clear yet whether it will be done
in multiple drafts or a single one. There is
On 2012-05-16 10:56, Andrew Sullivan wrote:
Because, after all, technical specification language is already such
elegant prose, maintaining that elegance is more important than
robustly encoding the semantic of being normative in a way that
avoids ambiguity?
One dreams of a period in which
On 2012-03-06 08:51, Julian Reschke wrote:
On 2012-03-06 14:41, Xavier Marjou wrote:
As a subscriber of the i-d-annou...@ietf.org list, I generally prefer
reading the HTML version of the draft rather than the TXT version.
I thus often need to manually rewrite the TXT link to fetch the HTML
On 2011-12-06 22:06, Benson Schliesser wrote:
ISPs need to use addressing within this scope that does not cause (additional)
problems for their existing customers (and their customers' equipment). And in
the event of an addressing conflict, operators (on both sides) need a common
reference to
On 2011-10-20 08:41, George, Wes wrote:
I'm also completely mystified as to why IPv6 support for all
proposed/requested features is not an explicitly stated requirement,
even at this phase.
And more generally, this should be considered an opportunity for
dogfooding the protocols we create.
Mykyta Yevstifeyev wrote, on 09/14/2011 01:10 PM:
Of course, you should have changed all references to vCard 4 to vCard 5, and
reference to VCARDDAV WG draft to RFC 6350.
vCard 4 is the latest version, specified in RFC 6350. We'll make a note to the
RFC Editor to update the references.
Simon
On 2011-06-20 23:52, John Levine wrote:
* There is no usable bus from the airport (it runs only at commuter
hours) and a taxi costs C$32.50
You're absolutely right about this. The people of Québec are not happy
about this situation and often complain in the media. It makes for a bad
first
On 2011-06-21 01:06, Randall Gellens wrote:
San Diego is much easier to get to than Quebec City, since multiple air
carriers serve it.
Not going to argue about San Diego vs Québec, but just going to point
out that multiple carriers do serve Québec. Among them are Air Canada,
United,
We wrote these instructions for those who want to fly to Montréal
instead of Québec:
http://ietf81.ca/?page_id=423
Simon
--
DTN made easy, lean, and smart -- http://postellation.viagenie.ca
NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca
STUN/TURN server --
On 2011-06-20 13:32, Michael Richardson wrote:
I'm staying at Laval University resident for $61/night. Hotwire did
find a few places equal in distance for ~$108, but the trip was harder
in my opinion. I might bring my folding bike, or not (I'm coming by
train). There are apparently dozens
On 2011-05-24 04:56, Julian Reschke wrote:
- to IANA: please fix the pages; XML parsers are not required to
understand that encoding name
IANA fixed it yesterday.
Simon
--
NAT64/DNS64 open-source -- http://ecdysis.viagenie.ca
STUN/TURN server-- http://numb.viagenie.ca
vCard 4.0
On 2011-05-20 09:37, Julian Reschke wrote:
Fun aside, ASCII is the wrong encoding to declare, either use
US-ASCII, or just drop the declaration (the default being the right
thing anyway).
The intent is to use UTF-8. We'll fix that.
Thanks,
Simon
--
DTN made easy, lean, and smart --
Please also refer to the results of the DNS64/NAT64 experiment that we
ran at IETF 77. Users of the service encountered a bug due to parallel
resolving in one particular operating system. We believe the bug is due
to that particular implementation. Parallel resolving is still a Good
Idea(TM), but
On 2010-06-17 12:55, David Conrad wrote:
Well, yes. However, applications already have to be modified to deal with
IPv6. I'd agree that modifying applications from a simple synchronous path
to dealing with parallel asynchronous connections would not be a good idea.
Personally, I'm of the
On 2010-04-06 13:56, Andrew Sullivan wrote:
I thought we didn't have members? I've always liked to refer to
people doing work here as participants for exactly that reason.
There are exactly 2003 members of the IETF! ;)
http://www.linkedin.com/groups?viewMembers=gid=83669
Simon
--
On Saturday 19 September 2009 15:55:55 Steve Crocker wrote:
The choice is between engaging and not engaging. Engaging is better.
Not engaging isn't constructive.
Thank you. I wanted to say this, but could not find the right words.
I fully agree with Steve Crocker.
In the long run, exposure
39 matches
Mail list logo
