Hi, On Tue, Apr 25, 2017 at 9:09 AM, John Bradley <[email protected]> wrote: > Thanks Kathleen, > > William and I will address these shortly. > > We can take out the IANA section completely if you think it is better.
No, I think it's fine. Let's see what happens. It could be helpful text for some readers, I was just pointing out that some questions may arise. > > In the current implementations on Android and iOS Universal Links/App Links > and are only http or HTTPS schema URI making them URL. > > So while all URL are URI, we could be more specific if that is OK with the > style police. I thought the URL term was currently discouraged.. You have it in a couple of places already, so consistency would be easier to argue if you felt it was needed in the places where it is already, hence my comment. I can't be sure what the URI style police will say, but consistency helps in most situations. If this is specific to an example, that's fine. If the general pattern could be a URI (not a URL), then just be sure that is clear in the text. Please let me know when it is ready and I'll start the IETF last call. Thanks, Kathleen > > John B. > > >> On Apr 24, 2017, at 10:47 PM, Kathleen Moriarty >> <[email protected]> wrote: >> >> Hello, >> >> Thanks for taking the time to document this best practice and the >> implementations in the appendix. I have one comment and a few nits. >> >> Security Considerations: >> I think it would go a long way to organize these as ones that apply to >> this best practice and ones (8.1 and the example in 8.2) about >> alternate solutions. This could also be done through some added text, >> but making this clear would be helpful. Maybe moving 8.1 and 8.2 >> until after the rest of the sections would be enough and then clearly >> state the intent of this text. >> >> IANA Section: >> Just a note - you might get some questions about this, but i do think >> it's fine to leave that text, although unnecessary. >> >> Nits: >> Section 5, punctuation >> OLD: >> By applying the same principles from the web to native apps, we gain >> benefits seen on the web like the usability of a single sign-on >> session, and the security of a separate authentication context. >> NEW: >> By applying the same principles from the web to native apps, we gain >> benefits seen on the web, like the usability of a single sign-on >> session and the security of a separate authentication context. >> >> The document has text that says 'native app' in some places and 'app' >> in others, I assume these are used interchangeably? It seems that >> they are used interchangeably. >> >> >> Really nitty: >> Section 7.2, >> Since you are still in the example, did you mean URL in the following: >> >> Such claimed HTTPS URIs can be used as OAuth redirect URIs. >> Such claimed HTTPS URLs can be used as OAuth redirect URIs. >> >> And again in the last paragraph of this section. >> >> I'm only asking since you specify URL earlier in this section, so you >> were more specific for the example and then drop back to URI (which is >> correct, but wondering if you wanted to continue at the same level of >> specificity or if there was a reason to just say URI here. >> >> Section 8.11 >> s/uri/URI/ >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > -- Best regards, Kathleen _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
