[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]