Re: [art] Stephen Farrell's Discuss on draft-ietf-appsawg-file-scheme-15: (with DISCUSS)

[Stephen Farrell <[e-mail]>]

On 13/12/16 16:11, Dave Crocker wrote:
> Steve,
> 
> Sorry, but I can't tell what the specific concern is...  Please clarify
> with specific references.

Sorry for being unclear.

AFAIK (though I could be wrong) this would be the first time
the IESG would have approved a proposed standard that directly
duplicates text that is on the whatwg's web page [1] where
they "define" (a la living std) URLs.

[1] is a normative reference in W3C specs.

If the above is the case, then I'd like the IESG to be explicit
about doing that and living with the brokenness of which Ned
gave us some examples.

There is no change request/suggested in the spec itself.

Cheers,
S.

[1] http://url.spec.whatwg.org/


> 
> Inline...
> 
> 
> On 12/13/2016 7:25 AM, Stephen Farrell wrote:
>> Appendix C: this spec and the whatwg web page may or may not
>> be in conflict.
> 
> 1. "May or may not" presumably means that your concern is we don't know.
>  But since that lack of knowledge could be applied to a potentially
> infinite set of web sites, what's the reasons for selecting this one to
> be concerned about?  Further since there's clear text in Appendix C and
> text at the whatwg (but you don't cite which page), it's not clear why
> the answer isn't clear.
> 
> 2. Since Appendix C is non-normative, what makes the concern of possible
> (but undocumented) divergence a reason for blocking with a Discuss?
> 
> 3. If there is a deeper concern that you are raising, I've missed it.
> 
> 
>>  I think this may be the first PS that we've
>> produced where that fact finally hits that fan - is that
> 
> What fact?
> 
> 
>> right? If not, then I'll clear as we'll already have decided
>> there's nothing to be done about odd behaviour with
>> "competing" specifications for the same thing (that thing
> 
> You haven't cited any competing specifications, not even possibly
> competing ones.
> 
> 
>> being RFC3986). If this is the first time we've gotten to
>> this point, then I think the IESG ought explicitly decide
>> that we are going to live with what we all know is a pretty
>> crap situation where different implementers (web vs. non-web
>> basically) supporting various kinds of URL/URI are liable to
>> end up doing different and potentially non-interoperable
>> things. (There is no action required from the author. For the
>> IESG - we discussed this a couple of years back, but there
>> have been some personnel changes since and I forget if the
>> current set of ADs are or are not up to speed with and ok
>> with this.)
> 
> 
> d/
> 
>