xri message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Comments on WD10ED05
- From: "Wachob, Gabe" <gwachob@visa.com>
- To: <xri@lists.oasis-open.org>
- Date: Wed, 22 Feb 2006 16:26:40 -0800
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]