- From: Ted Hardie <ted.ietf@gmail.com>
- Date: Wed, 21 Apr 2010 15:12:13 -0700
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: public-html <public-html@w3.org>, "public-iri@w3.org" <public-iri@w3.org>
Hi Sam, My apology for the delay; somehow this thread was not updating, so I missed your question until I manually checked the archive to see if my posting of the minutes came through. I'll confirm with Marc on the description and get the tickets opened. regards, Ted On Wed, Apr 14, 2010 at 1:16 PM, Sam Ruby <rubys@intertwingly.net> wrote: > On 04/08/2010 09:40 PM, Ian Hickson wrote: >> >> On Thu, Apr 8, 2010 at 9:31 AM, Ted Hardie<ted.ietf@gmail.com> wrote: >>> >>> my understanding is that the correct next step will be to describe this >>> issue >>> in a way that we can track. >> >> I've tried to write descriptions of the two issues. Please let me know >> if you need any further advice on the matter. > > Ted, I would appreciate any feedback the IRIbis WG may have on this input. > > - Sam Ruby > >> Issue 1: >> ======================================================================== >> Update the IRI specification to define an algorithm with the following >> characteristics: >> >> Input: >> * a string >> >> Output: >> * a boolean representing whether the algorithm succeeded or failed >> * if the algorithm succeeded, one or more strings corresponding to >> the following components, each of which may be present or absent: >> -<scheme> component >> -<host> component >> -<port> component >> -<hostport> component >> -<path> component >> -<query> component >> -<fragment> component >> -<host-specific> component >> >> This algorithm must be such that it can be used where HTML5 says "the >> user agent must use the parse an address algorithm defined by the IRI >> specification" in a manner that user agents including major browser >> vendors will be willing to implement the algorithm as written. >> >> Exactly what this algorithm must do is a matter that will need careful >> research, reverse-engineering existing UAs. >> >> The algorithm needs to be defined in such a way that it can be >> referenced unambiguously by name. For example, text such as the >> following could be used to introduce this algorithm: >> >> When a specification says that a user agent is to *parse an >> address*, given a string INPUT, it must run the following steps, >> which return a failure/success condition and a set of components: >> >> ... >> >> This gives a completely unambiguous and clear way to invoke the >> algorithm described in the spec, along with RFC2119-level clarity >> regarding what such invokations imply for the user agent. >> ======================================================================== >> >> Issue 2: >> ======================================================================== >> Update the IRI specification to define an algorithm with the following >> characteristics: >> >> Input: >> * a string A >> * a string B, which was previously output from this algorithm >> * a character encoding >> >> Output: >> * a boolean representing whether the algorithm succeeded or failed >> * if the algorithm succeeded, a string >> >> This algorithm must be such that it can be used where HTML5 says "the >> result of applying the resolve an address algorithm defined by the IRI >> specification to resolve url relative to base using encoding encoding" >> in a manner that user agents including major browser vendors will be >> willing to implement the algorithm as written. >> >> Exactly what this algorithm must do is a matter that will need careful >> research, reverse-engineering existing UAs. >> >> The algorithm needs to be defined in such a way that it can be >> referenced unambiguously by name. For example, text such as the >> following could be used to introduce this algorithm: >> >> When a specification says that a user agent is to *resolve an >> address", given a string INPUT, a second string BASE, and a >> character encoding ENCODING, it must run the following steps, which >> return a failure/success condition and a string: >> >> ..." >> >> This gives a completely unambiguous and clear way to invoke the >> algorithm described in the spec, along with RFC2119-level clarity >> regarding what such invokations imply for the user agent. >> ======================================================================== >> >> HTH, > > > > > >
Received on Wednesday, 21 April 2010 22:18:57 UTC