- From: Erik Nygren <erik@nygren.org>
- Date: Tue, 15 Oct 2013 15:10:27 -0400
- To: Eliot Lear <lear@cisco.com>
- Cc: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
- Message-ID: <CAKC-DJg1=2jyPaCZvf3duW8TjMyUY1TCCfarQ=Gws0ZBM1r-Hw@mail.gmail.com>
On Tue, Oct 15, 2013 at 7:42 AM, Eliot Lear <lear@cisco.com> wrote: > It does seem that someone should answer the question, "Why not use DNS > for this?" There's even a reasonable answer, which is that because this is > a header, you are piggybacking it with data. > Also, the proposal calls out: "Potentially, there are many ways that a client could discover the alternate service(s) associated with an origin; this document currently defines one, the Alt-Svc HTTP Header Field (Section 3<https://mail-attachment.googleusercontent.com/attachment/u/0/?ui=2&ik=4eec3a08b8&view=att&th=141bb1ffe146a105&attid=0.1&disp=inline&safe=1&zw&saduie=AG9B_P-Vj6Fz34Aqfn-A88HAaDut&sadet=1381863805889&sads=n52BEL0aHy8e1yfX6ATY1reYbCA#0.1_alt-svc> )." It would seem logical then that DNS could *also* be used for this with the same alt-svc data schema and semantics, with the values obtained via DNS and piggybacked with data being merge-able, as per: "Note that priorities are not specific to the mechanism that an alternate was discovered with; i.e., there is only one “pool” of priorities for an origin." Piggybacking this with the HTTP response/data may have a lower deployment barrier than introducing a new DNS RR type, plus there may be some ways of using this that are not possible via the DNS. Erik > > On 10/15/13 3:57 AM, Mark Nottingham wrote: > > We talked about using a response header for negotiation last week, a la > Alternate-Protocol, and one of my action items was to isolate the Alt-Svc > proposal. > > This draft is a first cut at proposal. I'm particularly interested on > feedback from client implementers on the straw-man interop testing proposal > at the bottom. > > Cheers, > > P.S. Friendlier HTML attached. > > > > > > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > draft-nottingham-httpbis-alt-svc-00.txt > > Date: 15 October 2013 12:54:42 AM PDT > > To: Mark Nottingham <mnot@mnot.net> <mnot@mnot.net> > > > > > > A new version of I-D, draft-nottingham-httpbis-alt-svc-00.txt > > has been successfully submitted by Mark Nottingham and posted to the > > IETF repository. > > > > Filename: draft-nottingham-httpbis-alt-svc > > Revision: 00 > > Title: HTTP Alternate Services > > Creation date: 2013-10-14 > > Group: Individual Submission > > Number of pages: 13 > > URL: > http://www.ietf.org/internet-drafts/draft-nottingham-httpbis-alt-svc-00.txt > > Status: > http://datatracker.ietf.org/doc/draft-nottingham-httpbis-alt-svc > > Htmlized: > http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-00 > > > > > > Abstract: > > This document introduces "alternate services" to allow an HTTP > > origin's resources to be available at a seperate network location, > > possibly accessed with a different protocol configuration. > > > > It also specifies one means of discovering alternate services, the > > "Alt-Svc" header field. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > -- > Mark Nottingham http://www.mnot.net/ > > > > >
Received on Tuesday, 15 October 2013 19:10:54 UTC