RE: [xri] Comments on draft-resolution-04

["Wachob, Gabe" <gwachob@visa.com>]

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