Subject: [apps-discuss] Applications Area Errata

From: Alexey Melnikov <[email-masked]>
Date: Mon, 26 Jul 2010 10:01:45 +0200

Greetings,
IESG has agreed to reduce the number of reported but unresolved errata.

Please review Errata for various Applications Area RFCs to see if you 
can help with any of them. Peter and I will also be sending some 
specific requests to relevant WGs.

Best Regards,
Peter and Alexey

RFC Number

(Errata ID)

Section

Type

Source of RFC

Responsible WG/BOF/person

Submitted By

RFC2157 (1387)

6.2

Editorial

mixer (app)

Frank Ellermann

RFC2288 (775)

-

Technical

urn (app)

URNBIS BOF

Alfred Hoenes

RFC2426 (868)

4

Technical

asid (app)

VCARDDAV

Javier Godoy

RFC2426 (869)

4

Technical

asid (app)

Javier Godoy

RFC2426 (870)

4

Technical

asid (app)

Javier Godoy

RFC2426 (872)

7

Technical

asid (app)

Javier Godoy

RFC2426 (1550)

4

Technical

asid (app)

Markus Lorenz

RFC2616 (411)

14.3

Technical

http (app)

HTTPBIS

WooJin Chung

RFC2617 (1649)

5

Technical

http (app)

Ganga Mahesh Siddem

RFC2617 (1914)

3.2.2.1

Technical

http (app)

Larry Westrick

RFC2821 (374)

4.2.5

Technical

drums (app)

YAM

Mathias Koerber

RFC2821 (375)

4.2.5

Technical

drums (app)

Jochen Topf

RFC3659 (901)

7.5.4

Technical

ftpext (app)

FTPEXT2 BOF

Alfred Hoenes

RFC3659 (1500)

7.7.4

Technical

ftpext (app)

Maik Reiß (Reiss)

RFC3977 (2003)

GLOBAL

Technical

nntpext (app)

Julien Élie

RFC3977 (2004)

GLOBAL

Technical

nntpext (app)

Julien Élie

RFC3982 (1305)

4

Technical

crisp (app)

Marcos Sanz

RFC4992 (1009)

-

Technical

crisp (app)

Alfred Hoenes

RFC4512 (2281)

A.3

Editorial

ldapbis (app)

Alfred Hoenes

RFC4519 (1761)

3.10

Technical

ldapbis (app)

Fotis Georgatos

RFC4823 (2282)

7.4.4

Technical

ediint (app)

Alfred Hoenes

RFC4823 (2283)

9

Technical

ediint (app)

Alfred Hoenes

RFC4918 (1207)

9.10.1

Technical

webdav (app)

Julian Reschke

RFC4918 (1519)

8.3

Technical

webdav (app)

Manfred Baedke

RFC4918 (1371)

9.2

Editorial

webdav (app)

Julian Reschke

RFC5162 (1365)

1. (ff.)

Technical

lemonade (app)

Lemonade/MORG

Alfred Hoenes

RFC5465 (2318)

3.1

Technical

lemonade (app)

David Woodhouse

RFC5546 (2331)

3.4.

Technical

calsify (app)

CALSIFY

Filip Navara

RFC3798 (691)

YAM

RFC3798 (692)

RFC4409 (98)

RFC4409 (2393)

RFC5321 (1543)

RFC5321 (1851)

RFC5322 (1905)

RFC5322 (1906)

RFC5322 (2104)

RFC5119 (1324)

URNBIS

RFC5134 (1325)

RFC5134 (1328)

RFC5279 (1516)

RFC4229 (161)

HTTPBIS

RFC4229 (837)

RFC4521 (69)

LDAP

RFC4524 (68)

RFC4526 (67)

RFC4529 (66)

RFC4529 (853)

RFC4532 (65)

RFC4234 (159)

ABNF

RFC4234 (777)

RFC4234 (778)

RFC4234 (783)

RFC4234 (866)

RFC5234 (1423)

RFC5234 (1424)

---

From: Javier Ubillos <[email-masked]>
Date: Mon, 26 Jul 2010 11:30:31 +0200

As being discussed right now in apparea, here's an individual
submisison.

Name Based Sockets
Draft: http://www.ietf.org/id/draft-ubillos-name-based-sockets-01.txt
Presentation:
http://www.sics.se/~jav/ietf78/namebasedsockets-IETF78-apps.pdf

Consider it a real "request for comments", because I do want comments :)

The question to apps-discuss is, what features are wanted/important to
application developers?
What should we do next?
What would make this fly?

// Javier Ubillos

---

From: Dave Cridland <[email-masked]>
Date: Mon, 26 Jul 2010 11:45:00 +0100

> What would make this fly?

I looked at this with some interest.

As some initial comments, I'm a little concerned about section 4 -  
mostly in as much as not understanding the implications.

I'm also disappointed to see that the port remains a number - I would  
have thought a string (or at least the option for one) would be  
useful here, allowing SRV record lookup, for example.

I suspect that a series of socket options for controlling the almost  
bottomless options here would be useful, too.

I suspect that if this could be made to handle non-blocking,  
single-attempt, SRV lookup, host lookup, and connection, then it  
would be very interesting to application developers. If it handled  
connection timeouts and retries transparently, all the more so.

This would give application developers a reason to use this even when  
SHIM6, etc, is not widely deployed.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Javier Ubillos <[email-masked]>
Date: Mon, 26 Jul 2010 13:04:40 +0200

On Mon, 2010-07-26 at 11:45 +0100, Dave Cridland wrote:
<snip>
> useful here, allowing SRV record lookup, for example.

About portnumbers, we are still discussing what to do about them.
In Christian Vogts article, the port number syntax is kept, but both
port fields are rather used as a flow identifier. Instead, the socket
has a "service" field, to denote which service one is looking for
[ http://tinyurl.com/2c3sndy ].
Personally, I'd like to explore ways of making the port fields both be
more router/firewall friendly and working as a kind of flow-identifiers.
E.g., that the port facing the "server" is a well known one, and that
the sender port is used as a flow identifier.
We're still exploring :)

> bottomless options here would be useful, too.
I agree totally, some ioctl() or, in abstractions some way of passing on
paramers to shut of (or turn on) certain features is a must.
If not for certain applications, definitely for development and
debugging.
 
> connection timeouts and retries transparently, all the more so.

I want to say "yes", but I'm gong to have to read up on it more in
detail. But I can't see why this would be a problem.
SRV in conjunction (or replacing) the service field would be a cool
thing.
When you talk about timeouts and retries, are you referring to some
particular protocol(s) or in general?

// Javier

---

From: Graham Klyne <[email-masked]>
Date: Mon, 26 Jul 2010 11:58:46 +0100

This sounds to me like a potentially useful idea, especially as it seems it can 
be deployed (initially) over existing protocols.

Some thoughts on reading through the draft, from the perspective of web 
application development:

Sect 2.  Mention of locators as accessing *hosts* - isn't the real problem here 
to access *services* (e.g. a replicated service)?

Sect 3.3.  Paras 2 and 3 are losing me.   Section 3.4 does better - maybe some 
merging/reordering here would help.

Sect 4.  Now I'm seeing this is taking place at the IP level, wondering if this 
is too low-down to benefit (some, many?) application requirements (cf. mention 
of service access per above).

I'm also wondering how or if name based sockets can help the initial service 
rendezvous - the protocol as described seems to focus on parties announcing 
their own names ... it's not clear that it helps for them to initially locate

Section 4.1.  Use of nonce, maybe could usefully be described a little further. 
  I _think_ the idea is to allow a session to be started, and move to a 
different location while the session is in progress, rather than just breaking 
the session. (e.g. mobile apps?)

Section 6. Until this point, I was expecting the proposal to address a wide 
range of issues where name->IP translation is less fixed than one might like, 
but in this section, it seems that mobility is the main target.  Which I think 
explains some of my previous responses.

Section 10.3. I guess this is a placeholder, though I'm not sure what for.  It 
has occurred to me that, especially for web applications, a way to embed these 
names in URIs is needed (since URIs are the starting point for many web app 
resource addresses/identifiers).  But I'm not sure if it makes sense for this to 
be done separately from the protocol (URI scheme) involved.  Suppose I'm using 
HTTP to access a replicated service:  how can I name the service in an http: URI 
to access that service.  The URI authority section seems to be the logical 
place, bug given that name based sockets are based on FQDN and other forms, do 
the socket names fit cleanly and compatibly into the URI authority structure?

...

Above are my comments from a quick skim of the draft.  I started this email to 
try and describe what I'd like to see as an application developer, but thought I 
should at least first skim the proposal.

So what I'd like to see is a library/libraries that I can deploy on common 
systems (Linux, MacOS, Linux) and access from a range of programming languages 
(Java, Python, etc.), and including including browser Javascript and use with 
minimal change to allow endpoint replication/rehoming/rendezvous for existing 
applications with minimal code changes.

This sounds to me like a big ask - as I write this, I'm trying (and not 
succeeding) [**] to think if there's a smaller, simpler step that could allow 
this exploration to take place.  What I can say is that just implementing a new 
feature (i.e. the address family) at the socket API level isn't going to help my 
kind of application development.

[**] maybe a combination of an Apache module and a tweak to the Python libraries 
would allow some experimentation with Python client/Apache-based web services? 
This isn't something I've thought through clearly.

An area I can see benefiting from this kind of framework (or what I imagine it 
might be :) is web browser AJAX clients talking to replicated web services, so 
being able to have Browser AJAX apps play with the protocols would be an 
important step in this case.  I imagine something similar would apply for mobile 
apps running in mobile browsers.

#g
--

Javier Ubillos wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Dave Cridland <[email-masked]>
Date: Mon, 26 Jul 2010 12:18:32 +0100

> particular protocol(s) or in general?

To connect to an XMPP service for example.com as a client, you:

Lookup SRV for xmpp-client at example.com.
While there exist records:
	For each priority:
		While there exist records at this priority:
			Perform random weighted selection of record.
			Remove record.
			Lookup address records.
			For each address record:
				If connect succeeds, EXIT.
Perform address record lookup of example.com
For each address record:
	If connect (to fixed port 5269, found via getservname()) succeeds,  
EXIT
FAIL

None of that is XMPP specific, it's normal SRV lookup with a fallback.

If you can do all that with the API, or do it in two steps (SRV then  
fallback) at least, and do it non-blocking, application developers  
will want to be your friend and buy you beer.

Dave.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 26 Jul 2010 13:27:09 +0200

Dave Cridland wrote, on 07/26/2010 01:18 PM:
>     If connect (to fixed port 5269, found via getservname()) succeeds, EXIT
> FAIL

The problem with this is that nothing guarantees that the SRV name and what's in
getservname()'s database (i.e. the port-numbers registry) are the same.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Dave Cridland <[email-masked]>
Date: Mon, 26 Jul 2010 12:35:40 +0100

> getservname()'s database (i.e. the port-numbers registry) are the  

Sure, which is why I'm saying we might want to split this.

One problem is that there's a distinction in this model (that I  
really didn't make very clear) between "There were no SRV records"  
and "None of the SRV records worked". In the former case, you do the  
fallback, and in the latter case, you don't - meaning you need to be  
able to distinguish between "The name lookup failed" and "The name  
lookup worked, but the connect failed".

I think given errno values, that's possible, but it's certainly a  
requirement.

Dave.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 26 Jul 2010 13:52:37 +0200

> Sure, which is why I'm saying we might want to split this.

If I understand you correctly, you are suggesting to replace the name_sock
member in struct sockaddr_name with two char * members, one of them for the SRV
lookup and another to be passed to getservname()?

Simon

---

From: Dave Cridland <[email-masked]>
Date: Mon, 26 Jul 2010 13:02:43 +0100

> lookup and another to be passed to getservname()?

I'm not quite that mad.

I'm thinking the API would either do SRV, or to known port, so  
application developers do:

fd = socket(PF_INET, AF_NAME, SOCK_STREAM);

if (connect(fd, {xmpp_domain, "xmpp-client"}) != 0) {
	if (errno == EADDRNOTAVAIL) {
		/* Failed due to name lookup; try address lookup */
		if (connect(fd, {xmpp_domain, 5269}) != 0) {
			throw Failure;
		}
	} else {
		/* Something else, give up now. */
		throw Failure;
	}
}

[...]

I'm probably badly abusing errno values there, but does this make  
sense?

Dave.

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 26 Jul 2010 14:10:14 -0400

Hi Dave,

--On July 26, 2010 1:02:43 PM +0100 Dave Cridland <[email-masked]> wrote:

> I'm probably badly abusing errno values there, but does this make sense?

That is not a complete example as it does not show the SRV lookup. With 
your previous pseudo-code example you showed the various nested loops 
needed to do SRV. Wouldn't it make sense for named sockets to take care of 
all that too? i.e. how about adding an AF_SERVICE option where the 
"address" is the service type and domain. Then the new api takes care of 
doing the SRV lookup (with all the proper priority/weight handling) and 
uses the host/port from that for the actual connection.

Another important aspect of this spec is what information is available to 
the clients about the sockets that are bound. In particular application 
layer operations such as certificate verification will need access to some 
underlying information from the "named" socket that the client would 
otherwise have known with the current way of doing things.

-- 
Cyrus Daboo

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 26 Jul 2010 05:12:08 -0700

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Dave Cridland
> Sent: Monday, July 26, 2010 3:45 AM
> To: Javier Ubillos; General discussion of application-layer protocols
> Subject: Re: [apps-discuss] Name based sockets - Making individual
> submissions know
> 

This got me thinking about MX records.  If I want to talk to a mail server for example.com, there's not only a specific port, but a specific set of hosts that should be tried and even in a particular order.  And if there is no MX record, there's an implicit one at the A record.

Seems to me there might be some other exceptional cases this would have to accommodate as well.

---

From: Javier Ubillos <[email-masked]>
Date: Mon, 26 Jul 2010 14:24:32 +0200

On Mon, 2010-07-26 at 11:58 +0100, Graham Klyne wrote:
<snip>

Thanks for the comments on the draft. I'll make sure things are clearer.

> their own names ... it's not clear that it helps for them to initially locate

I don't think I understand.
To get a hold of your friend, you need some way of saying "I want to talk to X".
What alternatives are there for X?
Being a "name" is one option...

> explains some of my previous responses.
As name based sockets grow, and more features become integrated, I see
this section (and the corresponding for other features) moving out to
their own drafts. The reason why this is the only thing we address in
this draft is because it's what we have right now.

> the socket names fit cleanly and compatibly into the URI authority structure?

Yes, section 10.3 is broken.

Are you thinking of putting:
"protocol://hostname.net/path/to/service"
Into a socket?
Perhaps that's not an entierly crazy idea :)
Where (regex) #(.**)://([^/]*)/(.*)# would be
protocol, host, service

<snip>

> This isn't something I've thought through clearly.

The way I see it is that by having a socket level API solution, the
different socket abstractions will start picking it up. Starting with an
open (GPL) C implementation helps (I think).

// Javier

---

From: Graham Klyne <[email-masked]>
Date: Mon, 26 Jul 2010 13:36:28 +0100

Reflecting further since my initial response...

What really appealed to me about the proposal was this from the abstract: 
"Applications are thus relieved of re-implementing features such as 
multi-homing, mobility, NAT traversal, IPv6/IPv4 interoperability and address 
management in general."

This implies that what we're talking about is something that applications *can* 
do for themselves, but shouldn't have to.  On this premise, it seems to me that 
the first step shouldn't be to creating new protocol elements and kernel 
modules, as they're clearly not necessary, but to create a common library that 
applications can use to handle these common requirements (if indeed, they are 
common requirements).  This offers a relatively low-cost way to explore the 
requirements space.

Later, as application requirements are better understood, it may make sense to 
migrate some of the functionality into operating system and/or protocol elements.

So, in summary, I fear the current proposal may be putting the cart before the 
horse [1].  But I think the goals are apposite and the topic is worth investigating.

#g
--

[1] Maybe a somewhat British-English idiom, meaning to "reverse the accepted 
order of things" -- 
http://www.phrases.org.uk/meanings/put-the-cart-before-the-horse.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 26 Jul 2010 05:43:26 -0700

> [email-masked]] On Behalf Of Graham Klyne
> Sent: Monday, July 26, 2010 5:36 AM
> To: Javier Ubillos
> Cc: [email-masked]

Actually, are these things something in the application layer has to think about in general?  It seems to me the stuff we're talking about, namely IP address and port resolution, don't know anything about most of the things in that list.  I've never written an application that can tell, or cares, whether or not it's on a multi-homed box, a mobile device, or behind a NAT.

---

From: Graham Klyne <[email-masked]>
Date: Mon, 26 Jul 2010 14:01:09 +0100

> To get a hold of your friend, you need some way of saying "I want to talk to X".

Yes, that's what I'm asking about ...

> Being a "name" is one option...

... but I couldn't see how that would work.  What "name" does the client ask 
for?  What does the protocol do with this name, given that at initiation, no 
information or acknowledgement of named-based-socket support has been received 
in the other direction.

> this draft is because it's what we have right now.

If development is to proceed at this level, I think a (small) range of use-cases 
should be considered.

A use-case I have in mind is web client applications (very many instances 
thereof) accessing a replicated read-only query service (imagine, say, an API 
for Google-style search, or a replicated service for SPARQL [1] queries against 
dbpedia [2]).  So I want to name the service without fixing the particular 
endpoint.  Maybe you regard this kind of thing as out of scope - in which case I 
think the scope needs more careful articulation.

[1] http://www.w3.org/TR/rdf-sparql-query/

[2] http://dbpedia.org/About

> Where (regex) #(.**)://([^/]*)/(.*)# would be

Actually, no, though that did cross my mind.  The half-baked notion I had was 
that one might be able to write:

   http://[[name]]/path/to/service

where "[[name]]" is some construct that might confirm to the current structure 
of URI "authority" elements:

[[
    authority     = [ userinfo "@" ] host [ ":" port ]
    userinfo      = *( unreserved / pct-encoded / sub-delims / ":" )
    host          = IP-literal / IPv4address / reg-name
    port          = *DIGIT

     :

    reg-name      = *( unreserved / pct-encoded / sub-delims )
]]
-- http://www.apps.ietf.org/rfc/rfc3986.html (Appendix A)

There's quite a lot of scope here for using alternative naming structures.  But 
in the first instance, I'd expect something that looks like and behaves rather 
like a FQDN would be needed, as anything else would break all sorts of current 
software systems.

> open (GPL) C implementation helps (I think).

Hmmm... see my later message.

But yes, an open implementation helps (though maybe not GPL, as I know that 
could put off a fair number of potential adopters).  A C library would be a 
reasonable starting point, as many language systems have mechanisms for 
interfacing to these.

But if application developers have to wait for other parts of the system to take 
up use of some arcane underlying element, we could be back into similar 
territory as IPv6 deployment, but with less urgency to succeed.

#g

---

From: Graham Klyne <[email-masked]>
Date: Mon, 26 Jul 2010 14:15:52 +0100

> Actually, are these things something in the application layer has to think about in general?  It seems to me the stuff we're talking about, namely IP address and port resolution, don't know anythin…

You have a good point - I guess it comes down to the intended scope.  If the 
goal is to make current applications just work when IP addresses change under 
the hood, then I agree.

In other messages, I've used an example of a replicated web service.

Attempting to show this isn't an isolated use-case, another application design 
where I've contemplated a maybe-similar requirement is seamless handover in 
replicated systems, for resilience.  (I'm noodling here about real-time 
control/monitoring systems using a pub-sub information propagation model where 
two or more "controllers" are maintaining synchronized state, and either (or 
both) can respond appropriately to any request.)

I'm quite prepared to be told these are out of scope.  And I'm beginning to 
think they maybe should be out of scope, as solving the problem of movable 
session endpoints could be a big enough step up.

#g

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 26 Jul 2010 06:41:03 -0700

> From: Graham Klyne [mailto:[email-masked]]
> Sent: Monday, July 26, 2010 6:16 AM
> To: Murray S. Kucherawy
> Cc: Javier Ubillos; [email-masked]
> > Actually, are these things something in the application layer has to
> think about in general?  It seems to me the stuff we're talking about,
> namely IP address and port resolution, don't know anything about most
> of the things in that list.  I've never written an application that can
> tell, or cares, whether or not it's on a multi-homed box, a mobile
> device, or behind a NAT.
> 
> You have a good point - I guess it comes down to the intended scope.

Indeed.  Independent of the actual details, it seems to me things like multi-homing, mobile and NAT are completely off-topic (i.e. if you're trying to obscure name resolution, you're certainly trying to hide details like that... but fortunately they're actually already hidden anyway.).

---

From: Javier Ubillos <[email-masked]>
Date: Mon, 26 Jul 2010 16:15:08 +0200

> migrate some of the functionality into operating system and/or protocol elements.

I'm happy to hear you describe it this way.
This reflects my view perfectly.

This should be distributed as an userspace library at first, so that
applications can make sure they do get what they want, independent of
what is supported under the hood.
As the library matures, it will start to "sink in" into the OS.

However, the current implementation is, for practical reasons, far more
kernel close ;)

// Javier

---

From: "t.petch" <[email-masked]>
Date: Tue, 27 Jul 2010 11:37:03 +0200

How does this relate to 
 http://christianvogt.mailup.net/pub/vogt-2009-name-based-sockets.pdf
as discussed and critiqued on the RRG list?

Tom Petch

---

From: Javier Ubillos <[email-masked]>
Date: Tue, 27 Jul 2010 13:06:47 +0200

It relates very much :)
It's the continuation of what was proposed in that article.

// Javier

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 29 Jul 2010 01:57:12 -0700

> particular protocol(s) or in general?

FWIW Stuart Cheshire made the point in an IETF plenary around IPv4 and 
IPv6 that there are benefits in doing things in parallel (both the DNS 
lookup of A/AAAA records and the connect on IPv4/IPv6). See 
http://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf

If we are going to provide a new API for applications (whether it is 
initially just a library or a new socket protocol family) I think it 
makes sense allowing the implementation do to things in parallel. 
Perhaps the application should be able to choose between serial and 
parallel.

    Erik

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 29 Jul 2010 12:01:22 +0200

agree with Erik. with the additional comment: default is parallel, 
serial has to be specified if wanting to do serial.

Marc.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: Javier Ubillos <[email-masked]>
Date: Thu, 29 Jul 2010 14:16:29 +0200

Just out of curiosity, can some one come up with a reason _not_ to do a
parallel lookup?

I can imagine a few debugging scenarios, but even those are a bit
forced.

// Javier

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 29 Jul 2010 05:38:44 -0700

> Just out of curiosity, can some one come up with a reason _not_ to do a

There is a performance issue when you e.g., do SRV lookup and the result 
has N results at the highest priority, and then there are M A/AAAA 
records for each of those, resulting in N*M IPv* addresses that you 
could try to connect to.

If N*M is two then it is probably OK to always do it in parallel, but if 
it is 100, then I think some sequencing should be applied.

    Erik

---

From: Javier Ubillos <[email-masked]>
Date: Thu, 29 Jul 2010 14:41:49 +0200

> it is 100, then I think some sequencing should be applied.

Ok, that makes sense. Thanks.
So perhaps a maximum of concurrent connections...

Either way, thanks, I see the point.

// Javier

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 29 Jul 2010 14:46:53 +0200

> [email-masked]] On Behalf Of Erik Nordmark
> Sent: Thursday, July 29, 2010 10:57 AM
> To: Javier Ubillos
> Cc: General discussion of application-layer protocols

Andrew and I wrote it up as "Happy Eyeballs" for IPv4, IPv6, SCTP, and
TCP.  We added a suggestion to 'trend' towards IPv4/IPv6/TCP/SCTP based
on the previous success of using the address family or transport.  The
idea is that if IPv6 has not been successful (due to firewall 
configuration, broken tunnel endpoint, or whatever), it makes no sense
to continue annoying the user with connection attempts that will only
timeout and fall back to IPv4 (or fall back to TCP).

http://tools.ietf.org/html/draft-wing-http-new-tech-00

-d