more comments inline..
-----Original Message-----
From: Graham Klyne [mailto:GK-lists(_at_)ninebynine(_dot_)org]
Sent: Monday, May 20, 2002 12:18 PM
To: Marshall Rose
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: WG Last Call: draft-ietf-opes-architecture-00
<snip>....<snip>....<snip>
Well... does it need to be "transparent"?
When I wrote my comments, I was thinking that there might be
HTTP access to
the audit trail (with appropriate authentication) from the
client system in
whose admin domain the OPES intermediary was operating. That
presumes the
client knows what URL to use to query the audit, so its not
transparent (in
the sense of being automatically available), but I think that is
information that could easily be made available.
(That was assuming an OPES intermediary on an HTTP flow; for (say) an
email flow, some variant of the mechanisms suggested by
multipart/external
might be used. The key issue here is that an end user with standard
off-the-shelf client software can access the diagnostic information,
without dependence on protocol extensions.)
Taking the "Internet Scale" discussion of the table, I kind of agree with
that. We had several discussions about this. My concern with headers
extensions is that we would need to do that for every single protocol that
OPES might use, which might slow down OPES adoption. Not only from an
implementation perspective but also that all these extensions would need to
go throught the IETF ptocess, sometimes spanning more than one working
group.
But the crux of the question then is, as you put it, how to convey this
information to end user in a way that with off the shelf software he can
check the audit trail. With HTTP would that be a Redirect? With email, would
that be a mime/multipart as you put it? And how about RTP, FTP, etc?