[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Comments on draft-resolution-04
Indeed, I enjoyed reading it as "An Introduction to XDI." This was very readable. In this respect, I would love to have some UML diagrams. Do you think Activity diagram is more suited for the resolution process, Gabe? I thought, since there are distinct objects and message passing among them involbed in the resolution, sequence diagram would be particularly useful. Now, as a spec., I have one concern. Perhaps I am traumatized by the experience of XNS spec, but this "size factor" is rather important as well. Think of the process that a new reader will do when first exposed to any kind of document. 1. Assess the volume: If too big, abort. 2. Look at the Contents/Index. If too hard, abort. 3. Start reading, and after a couple of pages, if he starts feeling weary, abort. etc. So called "Meta Recognition" is very important for human being's learning process, and what I fear is that those size factor would create a negative Meta Recognition. If it cannot be broken down to a smaller documents, then it would probably be nice to have "how to read" at the very beginning. Nat > -----Original Message----- > From: Wachob, Gabe [mailto:gwachob@visa.com] > Sent: Thursday, March 03, 2005 2:36 AM > To: Drummond Reed; Sakimura, Nat; xri@lists.oasis-open.org > Subject: RE: [xri] Comments on draft-resolution-04 > > I tend to agree with both of you actually. > > It certainly is not as terse as many protocol specifications. > And that makes me feel a little uneasy, but I'm not sure > there's a better way at this point. > > The resolution document has the dual task of introducing the > resolution concepts AND specifying the nitty gritty details. > I think there are precedents for this in SOAP, for example. > > As for UML diagrams - we could certainly add something like > an activity diagram. That would make it a bit longer though ;-) > > -Gabe > > > -----Original Message----- > > From: Drummond Reed [mailto:drummond.reed@cordance.net] > > Sent: Tuesday, March 01, 2005 11:15 PM > > To: 'Sakimura, Nat'; Wachob, Gabe; xri@lists.oasis-open.org > > Subject: RE: [xri] Comments on draft-resolution-04 > > > > Nat, > > > > Thanks so much, this is very helpful. I too thought that the > > Resolution spec was quite a bit bigger that Syntax and Metadata. > > However it is the area in which we are plowing the most new > ground (in > > Syntax, we are building heavily on URI/IRI, and Metadata builds > > heavily on Syntax and two other supporting specs). > > > > I also think that the examples help considerably in explaining the > > base spec. After reviewing it all in detail, I'm not as > sure that it > > could be "unpacked" and still be as readable. Ironically, I suspect > > the next version will be able to be much shorter because by > then the > > whole territory will be "better understood" (just as our 2.0 Syntax > > spec is now shorter than 1.0). > > > > Anyway, this is just my .02. Gabe, what do you think? > > > > =Drummond > > > > -----Original Message----- > > From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp] > > Sent: Tuesday, March 01, 2005 6:48 PM > > To: Drummond Reed; Wachob, Gabe; xri@lists.oasis-open.org > > Subject: RE: [xri] Comments on draft-resolution-04 > > > > Haven't finished reading it, but just a couple of points: > May overlap > > with other's comment since I have not checked them yet, but... > > > > Since line number seem to depends on the paper size, I am not using > > it. > > Instead I try to > > refer by section number etc. (We really should be using Wiki for > > this... > > or text base document > > with line breaks so that we can use diff and patch.) > > > > Table 4: The header shows xri://@:a:b -> xri://@!a!b , I guess. > > > > Section 2.3 > > "HTTP URL" -> "HTTP URI", I guess > > > > Section 2.3 Exabit of HTTPresponse: > > At XRIDescriptors/XRIDescriptor/Synonyms/External: > > It states xri://@example2/path > > At a glance, it seems it contradicts to the statement about local > > access in Section 2.2.8. If this is right, some > explanation is in > > order. > > > > Section 2.4.2 Frist line. > > ... section 4.3 or [RFC2483] -> ection 4.3 of [RFC2483] > > > > [GENERAL] > > I am a fresh-eye for this thing as I have not been involed in the > > process. (I regret.) However, this means I am uniquely > positioned to > > experience what the other people would feel when first > exposed to this > > document. > > > > Here are bullet points: (Sorry, I have no time now. I would expand > > them later. ) > > > > - BULKY > > - Looks more like a white paper than a spec. > > - Useful to have UML Sequence Diagram for the description of the > > resolution process. > > - One could condense the normative spec to perhaps only 10 pages. > > Better separate the bulky explanation (I found it > extremely useful, > > though) > > and the main spec. > > - Figure 2 hard to understand > > > > Well, time up... to be continued... > > > > > > > -----Original Message----- > > > From: Drummond Reed [mailto:drummond.reed@cordance.net] > > > Sent: Tuesday, March 01, 2005 7:46 AM > > > To: 'Wachob, Gabe'; xri@lists.oasis-open.org > > > Subject: RE: [xri] Comments on draft-resolution-04 > > > > > > Gabe, > > > > > > Some of my comments overlap with Peter's, plus I have > boatloads of > > > regular text editing comments (per the partially review > draft I sent > > > you this morning). I am 1/2 way through Trusted Res. and > will send > > > you my completed draft as soon as I am finished with it > (current ETA > > > ~6pm tonight). > > > > > > =Drummond > > > > > > -----Original Message----- > > > From: Peter C Davis [mailto:peter.davis@neustar.biz] > > > Sent: Monday, February 28, 2005 1:27 PM > > > To: xri@lists.oasis-open.org > > > Subject: [xri] Comments on draft-resolution-04 > > > > > > page 6 : figure 1 it might be more clear to also show what gets > > > returns in this diagram (assuming space allows) > > > > > > page 29 line 224: it is also possible to have @a*b*c be both an > > > authority (over *d) and a local access point is it not? > if so, then > > > i think this should be noted (actually, i think it is the common > > > case) > > > > > > line 286 & 289: "MUST no longer be relied upon" i think should be > > > phrased "MUST NOT be relied upon" (preferring the > normative negative > > > form) > > > > > > line 692: references "!" as a GCS Char for annotations, > which it is > > > no longer > > > > > > Table 4 line 698: ":" in col heading should be "!" > > > > > > line 1025: for 'reasonable' caching, whatever that means, it is > > > unlikely that authorities can/should be aware of > down-stream cache > > > duration directives, thus i think the advice concerning the cache > > > relative to the resolution chain should be dropped, and we should > > > simply point out that cache times may vary, and the > resolver should > > > simply adhere to the 'shortest-lived' cache for the resolution > > > sequence. > > > > > > section 2.7 general: nothing is said about caching > computations for > > > lookahead resolution... that is, the XRIDescriptors/XRIDescriptor > > > elements each may contain different caching. I think some > > > explanatory text such as "When look-ahed or proxied resolution is > > > used, the resolving client MUST expire the entire XRID when the > > > first expriration of a node in the resolution chain > described in the > > > XRID is > > reached." > > > In addition, i think some advice on how lookahead and proxies > > > compute the value for the HTTP Expires header for their response > > > back to the client, based on the cummulative expirations set buy > > > both the HTTP headers and Expires elements in the chain of > > > resolution steps they perform on behalf of the client. > > > > > > line 1075: might i suggest that since there may be other trusted > > > resolution proposals in the future, that we enrich the > mediatype for > > > the resolution request (Accept header) to > > > xdrd-t-saml+xml or something. > > > > > > line 1114: rather than explaining that =example and example.org > > > similarities are coincidental, why don;'t we just make them > > > different strings ;-) > > > > > > line 1483: fix reference to resolution section (2) > > > > > > line 1606: +1 on gabes note on requiring KeyInfo. > > > > > > line 1610: I think AUthorityID is a MUST, since it is required > > > within the processing instructions t the client, is it not? > > > > > > seciton 3 general: we may want to express versioning for > trusted res > > > (or res in general), so that we can better acommodate backwards > > > compat, should XRIRes ever need revisions (eg: > > > application/xrid-t:1-saml:2.0+xml or > > > $res*trusted/XRITrusted/($v*1)). prehaps more broadly, do > we want to > > > express a version in protocols as a general rule. > > > this is partially covered in 4.2.3, but i think it needs more > > > (perhaps _more_ is in the metadata spec, which i have not > > read yet ;-) > > > > > > Section 5 Sec concerns forthcomming shortly (tomorrow mid-day) > > > > > > --- peterd > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: xri-unsubscribe@lists.oasis-open.org > > > For additional commands, e-mail: xri-help@lists.oasis-open.org > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: xri-unsubscribe@lists.oasis-open.org > > > For additional commands, e-mail: xri-help@lists.oasis-open.org > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: xri-unsubscribe@lists.oasis-open.org > > For additional commands, e-mail: xri-help@lists.oasis-open.org > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]