ietf-openproxy
[Top] [All Lists]

IAB Treatment version head_sid14 available

2003-08-24 21:51:49


Here is a revision of the "IAB Treatment" draft, as promissed. I have
added a couple of examples as requested by Markus. I may also found a
way to reduce the level contravercy related to the IP Addressing
consideration. I hope this major change and other minor edits will
help address some of the Hilarie concerns, but I am sure more work
will be needed as we get more specific feedback.

While the current draft is sufficiently self-consistent IMO, there is
a lot of work still needed in other drafts to make "IAB treatment"
references valid. It would be nice to get a nod from IAB/IESG
regarding our current direction (based on the "IAB treatment" draft)
before we spent time documenting specific details (e.g., OPES-Via
header format for HTTP). We need to get WG consensus first, of course.

The log of major changes is quoted below. The latest snapshot,
including XML sources for those doing hands-on modifications, is
available at

        http://www.measurement-factory.com/tmp/opes/

Please comment.

Thank you,

Alex.

-------------- change log ----------------

 head-sid14

  *  Rewrote the Introduction to the IP addressing consideration.
     Do NOT explain how IAB considerations, if interpreted literary,
     do not satisfy important real-world constraints. Instead, use
     the "chain of OPES intermediaries" exception introduced by IAB
     itself to show that OPES architecture addresses IAB concerns as
     long as the "chain" is defined/formed for a given application
     message rather than being a statically configured application
     routing table of sorts. IAB had to add the "chain" exception to
     cover one of the most obvious real-world usage scenario. We use
     the very same exception to cover all usage scenarios we care
     about.

  *  Polished text explaining the differences between tracing and
     notification mechanisms.

  *  Added examples of OPES/HTTP traces.

  *  Be careful not to imply that all OPES intermediaries must obey
     bypass instructions. Bypass should be ignored when no non-OPES
     version of the content exists. Ideally, this may need to be
     polished further -- if there is no non-OPES version of the
     content, most IAB considerations probably do not apply because
     there is really no adaptation, only creation of content (and we
     should not restrict content creation).

  *  Added references to OPES "Communications" draft
     [I-D.ietf-opes-end-comm].

<Prev in Thread] Current Thread [Next in Thread>