Stephane, Michael, On Wed, Jan 23, 2013 at 04:34:27PM +0100, Scharf, Michael (Michael) wrote: > Stephane, > > Earlier versions explicitly had a reference to RFC 3958, explaining > that ALTO discovery requires an URI as output.
this is still in section 1, third paragraph of our draft. > > RFC 3958 states: "The expected output of this Application is the information > necessary for a client to connect to authoritative server(s) (host, port, > protocol) for a particular application service within a given domain." > > That seems to prevent returning an URI as needed by ALTO, right? > > Thanks > > Michael > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of Stephane Bortzmeyer > > Sent: Wednesday, January 23, 2013 10:43 AM > > To: Sebastian Kiesel > > Cc: [email protected] > > Subject: [alto] S-NAPTR? (Was: [[email protected]: I-D > > Action: draft-ietf-alto-server-discovery-07.txt] > > > > On Thu, Jan 17, 2013 at 11:27:42AM +0100, Sebastian Kiesel > > <[email protected]> wrote a message of 67 lines which said: > > > > > this new version of the ALTO server discovery draft is based on the > > > feedback we got during WGLC. > > > > I know it's late but I still have a question: why using > > U-NAPTR when S-NAPTR (RFC 3958) would be sufficient? > > > > Both examples in the draft -07 use no left-hand part in the > > regexp (and I do not see what could be used for this part) > > and therefore would work with S-NAPTR. Please have a look at the (cited) RFC 4848. Sec 4.6 says that the only type of allowed regexp is a "complete replacement" regexp, i.e., without backreference to some part of the input. regards, Sebastian _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
