Guidelines and Registration Procedures for URI Schemes
draft-ietf-appsawg-uri-scheme-reg-06

I am curious how the expert review required in the document interacts with bona-fide standards actions. There's already an ongoing discussion on that, and Barry has noted it in his on comments, so I will leave this as a comment. In particular I wonder if the "On receipt of a registration request" section of 7.2 should be different if the request was part of an IETF/IESG reviewed and approved action in the first place.

There are a lot of SHOULDs in this document. I wonder how an expert reviewer is supposed to interpret deviations from SHOULD level requirements. This is especially true in statements like "... SHOULD include clear security considerations or explain [why not]". The expert's life might be easier if there was some text encouraging that deviations from SHOULDs be accompanied by an explanation.

I support Stephen's comments and was wondering about privacy considerations for the contact information provided as well in scheme registration requests.  Just noting the concern would be good and maybe recommending using a generic organizational contact if possible cold work if that's possible, may not always be.

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 a@example.com to b@example.com), 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