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

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

Peter-
	Some questions on your feedback. I couldn't figure out your line
# references - they seem different than the PDF version of -04. But I
was mostly able to track. One comment I didn't track (ie couldn't find
the text you were referring to):

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

	THANKS

	-Gabe

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