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] XRD feedback from Scott


Scott Cantor supposedly wrote:
> Sec 2.2.2:
>
> Suggest use of UTC be made a MUST rather than a SHOULD. If I have to  
> support
> non-UTC anyway, the SHOULD is meaningless and it probably shouldn't  
> say
> anything to ensure proper support for non-UTC.
+1
> Uses the term "Discovery Document". Does this mean the XRD instance?  
> I would
> just use that term rather than adding a new one.
+1 Maybe rename the standard to agree with the meaning of discovery  
document (Simple Open Extensible Resource Discovery Descriptor Format  
Markup Language, pick any 7±2), or just call them resource description  
documents? Though that sounds confusingly similar to RDF. If nothing  
else, consistantly use whatever term ends up in the abstract  
(currently, "resource description (XRD documents)").

> Suggest it NOT try to compose with HTTP (e.g. the Expires header)  
> for ease
> of implementation and full agnosticism of the transport. Otherwise,  
> I would
> suggest not allowing for that overlap at all and require that only the
> transport dictate expiration, or that they have to match and  
> implementations
> can rely on either one.
I'm more worried about the security of this. On a signed doc, I'll  
have a much easier time invalidating your assertions by messing with  
this unsigned header. Since a doc past it's internal <Expires/> date  
is absolutely stale, why not say Expires: MUST match or MUST NOT be  
present. Seems like there might be caching considerations too.

Joseph Holsten


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]