Re: [url] Requests for Feedback (was Feedback from TPAC)

I'm going to be a bit less active for the next few days, but if you have 
time and interest, perhaps you might consider making one or more pull 
requests?

These changes seem reasonable, and are more likely to get noticed if 
they appear in the document instead of merely on www-archive.

- Sam Ruby

On 12/21/2014 02:04 PM, Larry Masinter wrote:
> If the request for liaison statement doesn't result in concrete action, there are alternative paths to pursue, so The following suggestions for github url repo still apply:
>
> * in Github repo, note problem statement:
>   * add  a note in the Contents section of the top level README.md pointing out the docs directory.
>   * Add a README.md in the 'docs' subdirectory pointing out the submission process for those unfamiliar with it (xml2rfc, datatracker)
>
> * add a preface that this document (draft-ruby-url-problem) is just a gathering focus for discussion and feedback, and its future in IETF is uncertain (noting liaison statement request as above)
>
> * I think it would be useful to reference the HTML5 kerfuffle over the link to the URL living standard from HTML5.  Fixing that is part of the motivation for liaison to get involved, as the HTML5 compromise was promised to be short-term.  Perhaps a subsection under W3C
>
> * URN work in IETF link: urnbis working group http://datatracker.ietf.org/wg/urnbis/charter/
>    * Note that http://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/ updates RFC 3986.  The URN work is under active development in IETF and should be listed.
>
> * Section 2.1 IETF doesn't mention file scheme.
>
>   * Organizations/W3C: I think the TAG's involvement is different (not involved in republishing WHATWG's document); is it 'insure liaison-type exchange' ?  I think it's useful to link archives public-ietf-w3c@w3.org under W3C as a previous venue of discussion.  [url-workmode] needs a little more context to make the link useful for an IETF audience (I say since I don't get why it's copied here).
>
> * 2.4 WebPlatform link to http://www.webplatform.org/stewards/   maybe 2.4 should be 2.3.x subheading to W3C, and not really a separate SDO.
>
> * 2.2 WHATWG link to https://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F
>
> * IDNA: More explicitly, RFC 3490 (IDNA) defines processing for 'IDN-aware domain name slots' (where "the host portion of the URI in the src attribute of an  HTML <IMG> tag" is given as an example. Later, "IDNA is applicable to all domain names in all domain name slots". So in mailto:user@host, is the host a IDN-aware domain name slot? A domain name slot at all?
>
> * I think we need a section on possible changes to the scheme registration document: instructions to IANA to modify boilerplate addressing terminology. Insure newly registered permanent schemes or scheme updates match URL Standard requirements.
>
> * Obsoleting 3986
> I think we could have a subsection on this topic, since it is controversial.
> List alternatives: leave as is, update 3986, define URI in URL standard as subset of all URIs....
> I think we need to assure continuity for other specs, for example.
>
> * Obsoleting 3987?
> Add subsection to plan for this. What other specs reference 3987 and need something new to point to. Note now-closed IRI WG deliverables, including 'comparison' (link to GitHub comparison issue), and 'considerations when dealing with IRIs and bidi languages' (link to GitHub bidi issue).
>
> * file URI scheme:  Is it possible to move the 'file:' parsing and description to a separate document, just to isolate the interaction with kerwin-file-scheme?
>
> * form query submission testing, and multipart/form-data test suite
> I have a framework for generating html forms and testing form submission which might be useful for testing URLs and x-www-url-encoded. I'd like some help adapting the tests, though.
>
>
>
>

Received on Sunday, 21 December 2014 19:26:39 UTC