RE: Alt-Svc over DNS

Hi Ben,

> Interesting.  I think as a server operator, if you want to be able to do this kind of cache purging, you can't use ALTSVC.  DNS is fundamentally not compatible with cache purging.  We could add some text to that effect.

I think that some text would help. Is "clear" perhaps worth prohibiting in the ALTSVC frame?

On a seperate point, you don't explicitly address the discussion of network change in RFC 7838 Section 3.1. This relates to the "persist" flag. With DNS ALTSVC, is the same behaviour inherited?

> I don't think this generates any meaningful change: ALTSVC is scoped to the origin, not to an IP.  If a client is performing A and AAAA queries, then it's a dual-stack client starting happy eyeballs.  The client just does happy eyeballs with these IP addresses, and the connection parameters specified in ALTSVC.

> If you think it's unclear we can add text for it, but it seems pretty straightforward to me.  We could equivalently say that it's as if you got an Alt-Svc that included the origin as the hostname, and then had to do happy eyeballs to connect.

I was thinking aloud in my previous mail. I do understand your response but think it might be missing the original point I was making. Here was my though process:

A pathological server may want to advertise different alternatives based on the IP family, and HTTP Alt-Svc theoretically supports the case - the origin will deliver the Alt-Svc information on the IP that the client is currently connected to. When the host is omitted, the IP of the alternative (and hence its family) is inferred from the connected-to origin. (Or I'm making up implementation detail...)

I don't know if the theoretical case needs addressing explicitly. I do think the sequence of actions in section 4.2 could be tightened up but that could be done in response to feedback from implementers of this spec at a later date.

Regards
Lucas