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

On 12/27/2014 01:20 AM, Larry Masinter wrote:
> I looked through the mail archives again and reviewed comments.
> I looked at comments from Mark, Bjoern, Roy, Julian, Graham ....
> Sending to you for the moment...

Cool.

> =========
> For Roy, http://lists.w3.org/Archives/Public/public-ietf-w3c/2014Dec/0088.html
> perhaps you could take your "great effort to Insure that:" and
> put it in the document as a requirement for updating 3986,
> so the interop testing for 3986-conformance doesn't have
> to be repeated if URL and 3986 agree for almost all values
> that 3986 considers valid, and the differences carefully
> explained and justified.

At the moment, this information is in 5.6 (third bullet).  I see it as a 
requirement on URL-LS, not as a requirement on RFC 3986.  Do you see 
this differently?

> (To do that with "file:" might need a special case pre-processor for
> the web, with the result translated/normalized.)

File may end up being implementation defined.  Perhaps that should be 
listed as a possible outcome.  See:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27518

https://mailarchive.ietf.org/arch/msg/apps-discuss/KyxFLw2FCwv7CSpiWAmLr8Ha7vc

> =========
> You took out the "This document is for discussion purposes", but
>   what I was trying to make clear in the abstract and introduction
> is that the intent of this internet-draft is not necessarily be published
> as an RFC (although doing so might turn out to be useful.) Just
> a forward reference.  A lot of the discussion from Mark was
> around what the intent of this document is.

Sorry about that.  You had a sentence that was trying to say two things, 
and when I simplified it, I may have left out something important.  As 
it is "this document is for discussion purposes" seems incomplete and 
verging on tautological.

If you are looking to capture Mark's sentiment, it wasn't that this 
draft is for discussion purposes it was that this draft won't achieve 
what we're trying to achieve.

I'm OK with saying that, but I'm not certain that it is needed.  I'd 
rather that the document capture what Mark proposes, specifically pursue 
liaison statements (which you added, thanks!), and possibly "have the 
W3C perform its work, while the IETF patiently waits for the result; 
once it’s more or less done, we can take appropriate steps to 
incorporate / reference / clarify relationships with the outcome"

-- http://lists.w3.org/Archives/Public/public-ietf-w3c/2014Dec/0059.html

If that is captured (and I agree it should be), I'd also like captured 
that I would prefer that we work together up front in order to minimize 
the risk that the results won't be palatable or compatible with IETF 
goals.  In fact, I would prefer that be stated strongly: that the longer 
the IETF delays, the greater the integration problems likely will be 
down the road.

For now, I've identified problems with both RFC 3986/7 and URL-LS.  I've 
temporarily held off addressing them in the hopes that I could see how 
future documents will be structured.  Starting in January, I plan to 
resume fixing technical bugs and addressing issues.

> ==========
> I think for 'naming' point out that IETF authors typically use
> URL and not URI or IRI, e.g.,
>   http://datatracker.ietf.org/doc/draft-singer-appsawg-mcast-url/
> just to pick a random one. I'll see if I can come up with more stats
> on use of URL vs URI in recent IETF internet drafts and RFCs.

Seems reasonable.

> ===========
> Graham made a passing comment about URL schemes that
> identify resources that are far from the web, by other protocols
> that use URIs without HTTP at all.  I'm sympathetic to the
> and maybe include this thought somewhere.

Seems reasonable.

> ==========
> Bjoern  comments:
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13507.html
> "differences among APIs for manipulating resource
> identifiers. I do not think that is a problem and does not need solving"
> is it explicitly labeled a non-problem? It could be just a wiki or web page,
> or a separate informational reference, it doesn't have to be here in URL,
> does it?

I and others see it as a problem.  I'd like to see it addressed. I care 
not whether that is done inside an IETF draft or elsewhere.  I would 
like to see those that wish to continue to use terms other than the ones 
specified in the DOM to participate in this discussion.

> " Parameterization:" I kind of agree that this isn't clearly a problem, it's a
> solution to possible interoperability and security problems.

Solution?  I believe that it is a *cause* of possible interoperability 
and security problems.  In the specific case of IDNA, endorsing having 
different user agents doing differ things doesn't further the goal of 
interop.

> "Interoperability" I like his note about kinds of problems but I don't think they
> are clear classes or category. Maybe just copy his examples and note
> that it might be useful way of thinking about interop problems and solutions.
> "specific scheme definition":  The 'problem' is that you can't 'simply require
> somebody' to update specific scheme specifications. I think some of the
> possible outcomes will make revision of scheme definitions easier or harder.
> It would be useful to review existing scheme definitions to see if they
> need update if we update 3986 or 3987. It's part of the due diligence needed
> to update a  'full standard'.

The current draft simply states that there are differences, and links to 
a web page which identifies differences.

I'm inclined to think that there is a possible outcome that is a bit 
more radical than what you propose.  In 2005, RFC 3986 was the best 
possible consensus that could have happened at the time.  Splitting out 
IRIs and other scheme definitions was a part of that.  The downside of 
that approach is that RFC 3986 doesn't capture the full definition 
needed to produce a URI.parse method, and the remaining RFCs never got a 
critical mass of attention.

Revisiting this in the other direction in 2015 may be in order.  Every 
modern language will have URI.parse as a part of its core runtime 
library.  Everything that is needed to produce such a method should be 
defined in one specification.  New schemes that don't break that 
definition can certainly be defined, but ones that would break that 
definition should be pursued in conjunction with an update to the base spec.

Deciding whether new schemes should be, by default, relative or absolute 
would be the first step.  See:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27233

> Dealing with Bjoern's comments is hard, but maybe a note for each acknowledging
> the comment, in the draft or as an issue?

I have no problem with the draft acknowledging the comments.

> =======
> Are there w3c Bugzilla bugs we should link to?
> Going through a search on URL issues shows lots of background
> information (mixed in, lots irrelevant). Can you think of better searches?
> https://www.w3.org/Bugs/Public/buglist.cgi?list_id=49773&product=HTML%20WG&product=WebAppsWG&product=WHATWG&short_desc=URL&short_desc_type=casesubstring

Most of the bugs listed there don't require coordination.  I guess I'd 
rather approach this from the other direction: identify areas that 
require coordination, and cite bugs as appropriate that support that 
specific need.

> ======
> Is there a possibility of turning URL-LS into an IETF RFC? The issue about
> trust, normative references, stability, change control should be mentioned, too,
> if we're going for full disclosure.

It is possible, but for that to work, it would need to be without 
pre-conditions.  In particular, publishing this content under an IETF 
RFC may be possible, but doing so wouldn't cause the the URL-LS effort 
to be abandoned.  I only see that happening if there is evidence that 
the IETF spec is better maintained than the WHATWG effort.  FYI: there 
is precedent for this, the WHATWG abandoned effort on a DOM related 
specification (events, I think?) after it became clear that the W3C 
version was more actively maintained.

> Larry
> --
> http://larry.masinter.net

- Sam Ruby

Received on Saturday, 27 December 2014 18:02:00 UTC