OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Comments on WD10ED05


I have been quite rushed in getting these comments out, but here they are. In general, the spec is getting close, but there are a bunch of small issues and a couple of mid-size issues. No show stoppers.
 
    -Gabe
 
-------------
 
Comments on the no-comments PDF  WD10ed05 rez draft (sorry, ED06 came out too late for me to start reviewing it):
 
line 157: I think there needs to be a "resolution architecture" section like we used to have in earlier drafts. Its really hard to understand how all this stuff is supposed to hang together without at least something like we used to have demonstrating the various phases of resolution
 
line 181-185: Instead of  comitting to a specific title and set of content for the implementor's guide, it would seem better to refer simply to "other non-normative documents produced by the TC". In general, we shouldn't be referring to non-normative non-existent documents in our normative specs...
 
line 220: Don't say "XRDs" in the same paragraph where you are defining "XRDS". Say "XRD elements" instead of "XRDs" to avoid confusion.
 
line 238: Is section 3.2 normative? I think it is, but the lead paragraph makes it sounds like its just illustrative...
 
line 296: (throughout) I think the use of the @ sign before attribute names is a little odd outside XPATH expressions... Opinions may differ.
 
line 300: Do we mean "xrd:idref" instead of "xrd:id"?
 
line 329-352: For each of these, we need to say whether the URI/XRI included has to be absolute or whether it can be relative. I'm not sure. Also, the three items (LocalID, CanonicalID, and Ref) are three variations of the same thing - perhaps we should mention that here?
 
line 437: Instead of saying "provide redundancy", I'd say "describe redundant services endpoints or for other reasons".
 
line 463: Should this section just be moved to section 6.3.1 since its only used there?
 
line 467: under the right column next to "none" - I'd say "Do not match (the containing service *element* is not currently active)"
 
line 484: It seems that this section assumes or implies a specific API (language like "input parameters", "return", etc). I think this implied model should just be stated in terms of being a reference - something like "resolution is defined in terms of a application/resolver where the application invokes a resolution function and is returned data from that resolution. This specification does not require any such interface, but it is useful to use this model to describe the functionality specified in this document. " (OK, something worded better than that).
 
line 487: Next to the _xrd_n line, "Boolean flag" is not a well-defined value type - what strings are included as "true" values? 1,True, TRUE,T,Y,Yes,YeS,TrUe? Maybe refer to the XML schema definition? ALso, next to the _xrd_m line, I'd note that this flag controls authority-only vs. authority+service selection functionality on the part of the resolver...
 
line 493: Its not clear in this section what component's behavior is being specified - is this the resolver client, the resolver server, the application using the resolver? I am reading the flowchart and there is a branch asking about "known community root authorty" - this implies an absolute XRI, which means that this is client resolver behavior, not authority server, for example.
 
line 520-538: I think this stuff should go much earlier in the document, perhaps as part of the resolution architecture section (or maybe not, if there is stuff in the res arch section which gives a different intro).
 
line 554: There are a couple of places where there is some "state" being carried around between flow chart blocks. This "State" should be formally named - such as the "list of services" or "list of URIs". It gets confusing, for example, when you say "next highest priority URI" without saying what ordered list this is in reference to..
 
line 570: A resolver may request lookahead resolution of whom? The terminology is easy to lose here - you should say "A resolving client may request lookahead resolutoin ... from an authority resolution server". This is a bigger terminology issue that needs to be cleaned up (resolver vs. authority resolver vs. application). Or at least the defintions need to be more explicit.
 
line 660: I'd prefer not allowing the non-versioned and versioned values for _xrd_t -- why not just use the versioned one?
 
line 668: Don't say "the second string is the query string" - this is confusing. The query string is usually understood to be the thing after the ? in an URI - I don't think that is what is meant here. You mean the thing being resolved (one or more authority subsegments).
 
line 694: The word "insignficant" can be validly  interpreted in two 100% opposite ways - better to use "treated specially" or "has special significance"
 
line 891: I think that there should be discussion about how refs are followed in the context of trusted resolution. That is, how do you verify an XRDS document when it has nested XRDS documents.
 
line 905:
     typo: March Services by Type should be Match Services by Type
     The "No Services selected?" should ask the question in the affirmative and should be in alignment with the "Match" verb. "Any services matched?"
 
line 919: Here again, we have implied API ("returned") - thats OK, but we should make sure that the implied API is at least acknowledged and explicitly described (as mentioned in line 484)
 
line 970: Is the removal of an entire segment to be performed at most once, or can you slice off multiple segments if you consume all the subsegments in more than one segment? Either way, should be explicit and say it here (since it says "repated begining with step 1" but also says "final subsegment .. (or the final segment if the segment contains only one subsegment)"... confusing. 
 
line 1031-1032: We should get an official persistent URL from OASIS if we are going to make normative references to (what amounts to) a registry of values of 2-level domains. Better yet, perhaps we shouldn't really say anything here since this purely operational and we've been very clear not to go there in our spec.
 
line 1053: typo: constructe -> constructed
 
line 1055: the boolean value issue again.
 
line 1071: We never use the synonyms word (I don't think) - perhaps we shouldn't introduce it here (or perhaps we should introduce it earlier and tie it to those three elements). Its a bit wierd to introduce synonyms here and then not really use the term anywhere else.
 
line 1080: "return the same XRD" - more accurately, its "return a XRDS document with the same final XRD". This also applies to the other sections. Need to be clear that the entire XRDS can (and most likely) will be different - the final XRD will be the same (except for the child elements of the XRD that you mention).
 
line 1113: I'm running out of time getting these comments in, but this description of means of preventing circular references is not right - I think it prevents legitimate XRDS documents that would not end up in a circular reference.
 
line 1124-1127: Is there enough detail here about how service selection would work when the constructed XRI contains a path? How does the remainder of the original XRI get constructed when the new XRI (the one in the Ref element) has a path?
 
line 1135: do we mean "xrd:idref" instead of "xml:idref" here?
 
line 1203: The term SEP is not defined.
 
line 1218: HTTP servers are supposed to only return content conforming to the types in the requestors Accept headers. I think (though we'll have to verify) that the exceptions are error responses. So I'd propose that a http proxy resolver has to respond with an error code (most likely a 5XX) with an XRDS (or maybe a text/plain, depending on whats being asked for by the browser?) Donno. Need to discuss.
 
line 1276: "obtain a redirect" is not terminology we've used before -- we don't even talk about redirects at all in the document, afaict.
 
line 1327-1337: I think this example is illegal - at least currently, known elements in the XRD namespace have to occur before non-XRD-namespace elements. Haven't checked the current schema to confirm this is still true. l
 
line 1376-1386: Again, we need to acknowledge the SAML specification here for our blatant use of their excellent text.
 
line 1408: "resolution mechanism MAY BE USED IN A WAY WHICH is dependent... XRI resolution response MAY BE dependent" - we don't require DNS (and in fact, many reasonable people may choose to deploy XRI authority resolvers and/or other services with URLs that don't use DNS at all).
 

__________________________________________________
gwachob@visa.com
Chief Systems Architect
Technical Innovation and Standards Management
Visa International
Phone: +1.650.432.3696   Fax: +1.650.554.6817
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]