RE: [xri] XRD feedback from Scott

["Drummond Reed" <drummond.reed@cordance.net>]

+1. That's exactly what we did in XRI Resolution 2.0. Will, you can see the
text in section 16.4.1 of
http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xri-resolution-
V2.0-cd-03.html.

=Drummond 

> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Sent: Thursday, May 28, 2009 8:57 AM
> To: XRI TC
> Subject: RE: [xri] XRD feedback from Scott
> 
> I agree.
> 
> We should simply state that clients should pay attention to the caching
> rules of the transport being used. At the same time we should clearly
> explain what <Expires> means and how to use it. I would leave it up to
> each client to decide how to handle both present.
> 
> EHL
> 
> > -----Original Message-----
> > From: Scott Cantor [mailto:cantor.2@osu.edu]
> > Sent: Thursday, May 28, 2009 8:54 AM
> > To: 'XRI TC'
> > Subject: RE: [xri] XRD feedback from Scott
> >
> > Eran Hammer-Lahav wrote on 2009-05-28:
> > > I am not sure how much we need to spell out the relation between the
> > > transport caching directives to the document's expiration directives.
> > While
> > > they are used pretty much the same way, they have slightly different
> > > semantic meanings. In practice, if used over HTTP, the way the spec
> > is
> > > written today is how it should be implemented (the earliest
> > expiration
> > date
> > > of the two). Otherwise you violate either HTTP or XRD (or both).
> >
> > It's true that caching policies are not the same as "validity" rules.
> > In
> > other words, I think I would agree that they aren't semantically the
> > same,
> > unless the XRD element is meant solely as a caching hint. So, no, I
> > wouldn't
> > agree that you should just use the earliest for *validity* purposes. As
> > an
> > example, if I get one that the HTTP layer says should be refetched, but
> > is
> > still valid according to the XRD itself and I can't connect to the
> > source
> > again to refresh it, should I rely on it?
> >
> > -- Scott
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php