On 07/20/11 01:24, Sabahattin Gucukoglu wrote:
On 20 Jul 2011, at 00:34, Doug Barton wrote:
On 07/19/2011 14:01, Sabahattin Gucukoglu wrote:
Clearly, the view that making something historic when it's in active use is
offensive. No standards body could seek to stand behind their
I support the publication of this document.
In general, the document is clearly written, explains the processes
followed for gen-Art review, and forms a valuable snapshot of the
procedures followed at this time.
It makes it very clear that the document does not, in any way, shape or
form,
This is a summary of a followup review of the draft, after the one noted in
Ticket #35 of the trac wiki for this draft:
http://trac.tools.ietf.org/group/iab/trac/ticket/35
The complete version of this second review is at:
http://trac.tools.ietf.org/group/iab/trac/ticket/35#comment:2
On Thu Jul 21 17:06:59 2011, David Endicott wrote:
DNS resolution is not a function of a transport protocol.
I entirely agree, but the specification already includes DNS
resolution as part of URI resolution and URI scheme definition, and
as such, if you want all these things - which are, I
--On Thursday, July 21, 2011 11:40 +0200 Harald Alvestrand
har...@alvestrand.no wrote:
...
Actively being used. In production. So that taking it away
would hurt the entity using it, threaten the entity's comfort
and convenience, or just generally go against the stated
goals of making the
On Thu Jul 21 18:18:31 2011, David Endicott wrote:
It is my opinion that name resolution (however done) is outside the
purview
of WS. It may be handled in any number of ways by the client, and
must
happen *before* WS establishes it's TCP connection and begins
handshaking.
The URI scheme
On Thu Jul 21 19:43:07 2011, David Endicott wrote:
I do not know SIP or XMPP well enough to comment on why they
mandated the
name resolution mechanisms they did.However, XMPP is used in a
highly
dynamic host environment, so having flexible extensible name
resolution is
likely an
Costin,
The proposed -06 version sufficiently clarifies my one open issue.
I agree that the NSDI paper is an important citation and did not intend to
suggest that it be removed. In addition, your decision to not cite RFC 3124
is ok with me.
Thank you for responding to the review.
Thanks,
*PRELIMINARY* Agenda
IRTF Open Meeting
Quebec City, Canada
July 11, 2011, 9:00 - 11:30 (tentative)
Will be uploaded to the datatracker as soon as I have access rights.
Slot lengths below indicate presentation+discussion time.
State of the IRTF
Lars Eggert
10+5 min
Applied
2011/7/19 Dave Cridland d...@cridland.net:
Hi, I assume there is no interest in making DNS SRV mechanism exposed
in http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02 part of
the WebSocket core specification, neither referencing it (in the same
way RFC 3261 SIP protocol mandates the
I am opposed to inclusion in core specification. I would accept it as
optional extension.
DNS resolution is not a function of a transport protocol. DNS SRV has no
special association with WS.It is my opinion that this would be
additional cruft that is only marginally related to the purpose
2011/7/21 David Endicott dendic...@gmail.com:
DNS resolution is not a function of a transport protocol. DNS SRV has no
special association with WS. It is my opinion that this would be
additional cruft that is only marginally related to the purpose and function
of websockets. It does not
On Thu, Jul 21, 2011 at 06:27:49PM +0200, Iñaki Baz Castillo wrote:
2011/7/21 David Endicott dendic...@gmail.com:
DNS resolution is not a function of a transport protocol. DNS SRV has no
special association with WS. It is my opinion that this would be
additional cruft that is only
2011/7/21 Willy Tarreau w...@1wt.eu:
I understand the point David is making. DNS is something independant of
WS and conversely. It is one way of resolving addresses, just like there
will be people using hosts files. At no place the protocol specification
dictates how a client should resolve a
Thanks Willy, you made my point better than I did.
It is my opinion that name resolution (however done) is outside the purview
of WS. It may be handled in any number of ways by the client, and must
happen *before* WS establishes it's TCP connection and begins handshaking.
DNS, DNS SRV, etc.
2011/7/21 David Endicott dendic...@gmail.com:
It is my opinion that name resolution (however done) is outside the purview
of WS. It may be handled in any number of ways by the client, and must
happen *before* WS establishes it's TCP connection and begins handshaking.
DNS, DNS SRV, etc. are
On Thu, Jul 21, 2011 at 07:15:13PM +0200, Iñaki Baz Castillo wrote:
If WS spec does not mandate DNS SRV resolution in WS clients (so
webbrowsers mainly) then let's forget SRV balancing/failover
capabilities. If the WS core draft does not want to handle this topic,
then refer to another
2011/7/21 Dave Cridland d...@cridland.net:
It's proven impossible, despite effort, to retrofit SRV onto HTTP; there is
no way it'll be possible to retrofit onto WS.
Right. If WS borns with no SRV (as a MUST for WS clients) then just
forget it and let inherit all the ugly limitations from HTTP
I am strongly opposed to any MUST definition for any type of URL resolution.
I'm ok with inheriting / mimicking HTTP.Since it is intended to live in
the same universe as HTTP, I'm ok with it sharing mechanisms / limitations.
On Thu, Jul 21, 2011 at 1:52 PM, Iñaki Baz Castillo
2011/7/21 David Endicott dendic...@gmail.com:
I am strongly opposed to any MUST definition for any type of URL resolution.
SIP and XMPP mandate (MUST) a resolution mechanism based on NAPTR, SRV
and A/ records. Are they also wrong? do you also oppose to the DNS
MX resolution (as mandatory)
I do not know SIP or XMPP well enough to comment on why they mandated the
name resolution mechanisms they did.However, XMPP is used in a highly
dynamic host environment, so having flexible extensible name resolution is
likely an excellent choice.
I do not oppose DNS's MX records for SMTP as
I have no idea what you might mean by highly dynamic host environment in
this context, but XMPP servers are normally found at the same location
consistently. However, it is *not* always (or typically) the same location
as a simple A record lookup:
That's what I meant. XMPP systems have
On Thu Jul 21 21:57:23 2011, David Endicott wrote:
I have no idea what you might mean by highly dynamic host
environment in
this context, but XMPP servers are normally found at the same
location
consistently. However, it is *not* always (or typically) the same
location
as a simple A
On Thu Jul 21 18:33:38 2011, Willy Tarreau wrote:
If someone were to develop a backup/restore solution based on WS,
it would
be funny to discover that it cannot be used to restore the DNS
server when
this one fails...
If SRV (with a fallback) is defined as part of the core spec, this
On Thu Jul 21 23:15:59 2011, Bruce Atherton wrote:
So if you have no control over the DNS, it is not a problem. The
host will be resolved exactly the same way as it is now, using a
hosts file or A record or whatever. The only change is that the
client is required to try to use the more
From: Lars Eggert [lars.egg...@nokia.com]
*PRELIMINARY* Agenda
IRTF Open Meeting
Quebec City, Canada
July 11, 2011, 9:00 - 11:30 (tentative)
You say the meeting was 10 days ago and only the preliminary agenda is
available?
Dale
___
Ietf mailing
In message c125cd63e1264e518a4c7...@pst.jck.com, John C Klensin writes:
--On Thursday, July 21, 2011 11:40 +0200 Harald Alvestrand
har...@alvestrand.no wrote:
...
Actively being used. In production. So that taking it away
would hurt the entity using it, threaten the entity's
Dave Cridland wrote:
It's proven impossible, despite effort, to retrofit SRV onto HTTP;
Where is a proof?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
In message 4e28c035.6020...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes:
Dave Cridland wrote:
It's proven impossible, despite effort, to retrofit SRV onto HTTP;
Where is a proof?
Masataka Ohta
Transitioning HTTP to use SRV is trivial
On Jul 21, 2011, at 10:16 PM, Mark Andrews wrote:
In message 4e28c035.6020...@necom830.hpcl.titech.ac.jp, Masataka Ohta
writes:
Dave Cridland wrote:
It's proven impossible, despite effort, to retrofit SRV onto HTTP;
Where is a proof?
IETF Community:
This is a message for your information.
Last year we archived some legacy text files and notified the IETF community
which ones those were. This is follow-up message with a new set of registries
that have been both converted and archived. A total of 78% of the registries
we
In message 0dd53760-9b8a-4569-8c67-81421a8a2...@network-heretics.com, Keith M
oore writes:
On Jul 21, 2011, at 10:16 PM, Mark Andrews wrote:
=20
In message 4e28c035.6020...@necom830.hpcl.titech.ac.jp, Masataka =
Ohta writes:
Dave Cridland wrote:
=20
It's proven impossible, despite
On Jul 21, 2011, at 11:43 PM, Mark Andrews wrote:
I'm fairly convinced that in the vast majority of cases, SRV is a bad =
idea. DNS is already too out of sync from hosts in many situations; SRV =
just makes the situation worse. Or to put it another way, if you want =
to give every DNS admin
Total of 125 messages in the last 7 days.
script run at: Fri Jul 22 00:53:01 EDT 2011
Messages | Bytes| Who
+--++--+
8.80% | 11 | 8.85% |75151 | john-i...@jck.com
5.60% |7 | 8.49% |72097 |
Mark Andrews wrote:
Transitioning HTTP to use SRV is trivial even with proxies.
Transitioning HTTPS to use SRV is complicated because of proxies.
There needs to be changes to how clients talk to proxies for HTTPS
+ SRV to work through proxies.
What's wrong with:
https://www.example.com
In message 4e290442.3010...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes:
Mark Andrews wrote:
Transitioning HTTP to use SRV is trivial even with proxies.
Transitioning HTTPS to use SRV is complicated because of proxies.
There needs to be changes to how clients talk to proxies for
81st IETF Meeting
Quebec City, Canada
July 24 - 29, 2011
Host: Research In Motion (RIM)
Register online at: http://www.ietf.org/meetings/81/
1. Registration - Pre-Registration and Pre-Payment Cutoff is Friday, 22 July
2011
2. Companion Program and Events
1. Registration - Pre-Registration and
The Network Configuration (netconf) working group in the Operations and
Management Area Area of the IETF has been rechartered. For additional
information, please contact the Area Directors or the working group
Chairs.
Network Configuration (netconf)
--
38 matches
Mail list logo
