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: 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]