Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-uri-scheme-reg-05: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 07 Apr 2015 15:24:25 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-appsawg-uri-scheme-reg-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I put what I think it my most important comment first and hope
to see a response to that. (I don't think it'd be correct for
it to be a DISCUSS, but it's close.)

- 3.7, probably too late in the day to ask for it, but if
there are privacy considerations those would also be good to
note - and there will be for some of the application-specific
schemes, that e.g. have personally identifying information in
the scheme specific part. I'd suggest that renaming 3.7 to
"security and privacy considerations" would be good and saying
e.g. that where the scheme specific part is likely to be
privacy sensitive, then that ought be documented and ways of
minimising privacy-unfriendliness ought be documented.

- 3.2, all except the last para: I personally think the
SHOULDs here are bogus. Why does it matter at all, really?  In
any case, even if you maintain it matters, I'd suggest adding
a bit saying that even minor deployment is a reasonable
justification for going against the SHOULDs. If that's not
likely to garner immediate consensus, as I suspect, then I'll
not insist - we can drop the topic and leave it to folks
registering new schemes to continue to battle the URI
police:-(

- 3.2, last para: I'd suggest moving this quite reasonable
constraint away from the rest of this section.

- 3.6, 2nd para: I don't think you've quite said what you mean
here. "As restrictive as possible" could favour "all octets
are U+00A2" - that is very restrictive, but would be
problematic for many parsers I guess. (The U+00A2 value has no
specific significance.) I think what you meant to say was that
the scheme specification SHOULD be as close as possible to (or
deviate as little as possible from) what is allowed in 3986.

- 3.8: (very nitty nit:-) com.example.info isn't a good choice
as both com and info are gTLDs which may confuse some reader.
I'd suggest com.example.mything or similar.

- 3.8: I'm not sure, but are you really saying here that the
these scheme, after you take away the rightmost component,
ought be in the public suffix list? If so, that might actually
be good guidance as com.example.a.b.c.d is much more likely to
suffer bitrot over time I'd say. (Compared to com.example.abcd
I mean.)

- 7.3, 1st para: it'd have been nice if you could have avoided
IESG action being required for some details (e.g.  a change of
contact address from [email-masked] to [email-masked]), but I
guess that might be too tricky to get right in text, so ok.

- I agree with Ben's comment wrt loads of SHOULDs

---

From: Dave Thaler <[email-masked]>
Date: Wed, 8 Apr 2015 01:56:22 +0000

> -----Original Message-----
> From: apps-discuss [mailto:[email-masked]] On Behalf Of
> Stephen Farrell
> Sent: Tuesday, April 7, 2015 3:24 PM
> To: The IESG
> Cc: [email-masked]; [email-masked]
> Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-
> uri-scheme-reg-05: (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> I put what I think it my most important comment first and hope to see a
> response to that. (I don't think it'd be correct for it to be a DISCUSS, but it's
> close.)
> 
> - 3.7, probably too late in the day to ask for it, but if there are privacy
> considerations those would also be good to note - and there will be for some
> of the application-specific schemes, that e.g. have personally identifying
> information in the scheme specific part. I'd suggest that renaming 3.7 to
> "security and privacy considerations" would be good and saying e.g. that
> where the scheme specific part is likely to be privacy sensitive, then that
> ought be documented and ways of minimising privacy-unfriendliness ought be
> documented.

As current editor, I have no objection to that (and I think it's still in line with
the intent of the current text).  Personally I consider privacy considerations 
to just be a subtype of "security considerations" (i.e. already implied)
but I agree it's useful to call out to make sure people don't forget.

> - 3.2, all except the last para: I personally think the SHOULDs here are bogus.
> Why does it matter at all, really?  In any case, even if you maintain it matters,
> I'd suggest adding a bit saying that even minor deployment is a reasonable
> justification for going against the SHOULDs. If that's not likely to garner
> immediate consensus, as I suspect, then I'll not insist - we can drop the topic
> and leave it to folks registering new schemes to continue to battle the URI
> police:-(

It matters because people may not get the behavior they think they get.
The third paragraph at least now explains this more clearly.   The SHOULDs
apply to 'permanent' registrations, especially IETF Standards-Track documents.
So I think the "URI police" will (or ought to) be looking for IETF docs that don't follow the
SHOULDs and help authors/WGs just like there's MIB doctors, i18n experts,
security reviewers, etc.

> - 3.2, last para: I'd suggest moving this quite reasonable constraint away from
> the rest of this section.

I don't follow what you're suggesting.  The last paragraph is still about
syntactic compatibility.

> - 3.6, 2nd para: I don't think you've quite said what you mean here. "As
> restrictive as possible" could favour "all octets are U+00A2" - that is very
> restrictive, but would be problematic for many parsers I guess. (The U+00A2
> value has no specific significance.) I think what you meant to say was that the
> scheme specification SHOULD be as close as possible to (or deviate as little as
> possible from) what is allowed in 3986.

No... from my understanding (discussed in Dallas with at least one other co-author
since this predates my time as editor), it means as restrictive as possible (i.e.,
_more_ restrictive than "anything allowed in 3986").

Also keep in mind the saying usually attributed to Einstein, 
"Everything Should Be Made as Simple as Possible, But Not Simpler".

> 
> - 3.8: (very nitty nit:-) com.example.info isn't a good choice as both com and
> info are gTLDs which may confuse some reader.

Good point about .info, though pretty much anything reasonable we pick would be
a legal gtld too so I think this is unavoidable.   (I could go register ".mything" if
I had the money...)   That said, I have no objection to changing to use "mything".

> - 3.8: I'm not sure, but are you really saying here that the these scheme, after
> you take away the rightmost component, ought be in the public suffix list? If
> so, that might actually be good guidance as com.example.a.b.c.d is much
> more likely to suffer bitrot over time I'd say. (Compared to com.example.abcd
> I mean.)

There is no intent to introduce any dependency on a "public suffix list".
The point is to recommend using a DNS domain name that is allocated to you.

> - 7.3, 1st para: it'd have been nice if you could have avoided IESG action being
> required for some details (e.g.  a change of contact address from
> [email-masked] to [email-masked]), but I guess that might be too tricky to
> get right in text, so ok.

We already require less IESG actions than RFC 4395 did.
But yes it's tricky to get any better than the current text.

-Dave

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 08 Apr 2015 03:11:20 +0100

Hi Dave,

> but I agree it's useful to call out to make sure people don't forget.

If there's agreement with adding a bit of text like that, I think
that'd be very good. I suspect a lot of the application-specific
schemes could involve privacy sensitive information in the scheme
specific part and such text might help those defining schemes, or
implementing, to do better. I'm happy to try help craft text if
that's useful.

> It matters because people may not get the behavior they think they get.

Right, that's what I've never understood (or perhaps accepted;-). But I
do accept that other sensible folks consider it important, while at the
same time thinking: nah - that's irrelevant nonsense - a parser won't be
either helped or hindered by any of these SHOULDs. Anyway, I'm fine
with letting this go.

> I don't follow what you're suggesting.  The last paragraph is still about

Ah, 'twas just that I think the last para is sensible but those
preceding it in 3.2 are not. Ignore me again:-)

> "Everything Should Be Made as Simple as Possible, But Not Simpler".

Right, but you didn't say "but no simpler" in the text. And that is an
aspect of the cliche that is frequently ignored.

> The point is to recommend using a DNS domain name that is allocated to you.

I'm fine if that kind of thing is considered too much detail.

> But yes it's tricky to get any better than the current text.

Yep.

Thanks,
S.