WREC Working Group

1. WREC Working Group IETF 49, San Diego Co-Chairs: Mark Nottingham Ian Cooper mnot@akamai.com icooper@equinix.com

2. Agenda • Introduction (2 min) • WREC Status (13 min) • Intermediary Discovery and Description (20 min) • Resource Update Protocol (20 min) • Conclusions / Next Steps (5 min)

3. WREC Status • New Co-Chairs • Known-Problems update • Taxonomy update • WREC wrap-up • Motivation for New Work • Proposal

4. Known-Problems Update • Document format has been updated • Almost ready for “working group” last call • Revision 3 is public, revision 4 expected to be available around the end of this week (see Ian)

5. Taxonomy Update • RFC Editor sent back because: • It used a number of URLs as references • It appeared to quote I-Ds as normative references • Has been fixed (hopefully) – returned to IESG • Copied to WREC mailing list because it did not re-enter I-D queue

6. WREC Wrap-Up • Work items are nearing completion • Group needed more focus; getting bogged down in completing work items • “Rechartering” to gather focus, get fresh start but still leverage WREC’s work

7. Motivation for New Work • WREC has identified issues in the Web infrastructure (known-problems) • Community interest in tools that may be used to solve problems in the Web infrastructure

8. Proposal • Recharter WREC into WEBI (WEB Intermediaries) • Work items: • Intermediary Discovery and Description • Resource Update Protocol • Today: validation, scoping and determination of next steps • Not today: specific proposals, low-level details • Discussion encouraged, please keep comments topical and brief

9. Intermediary Discovery & Description • Background • Scope • Design Goals • Issues – Discovery • Issues - Description • Next Steps

10. IDD - Background • WREC identified issues with interception proxies • Interception proxies are widely deployed because there is no standard, effective way to configure the use of a proxy

11. IDD - Background (2) • PAC is poorly defined- Javascript, different client behaviors • WPAD is not widely deployed in clients – lack of integration into configuration format, too many options • Additional identified problems might be addressed in a client configuration mechanism • Solution needs to be standardized

12. IDD – Scope Discussion  • Describing network attributes and overlay of intermediaries as accurately as possible, to enable clients to correctly route requests • Intermediary implies proxy, gateway or surrogate • Client implies user-agent or intermediary • Design for use in a single administrative domain • Two components: Discovery and Description

13. IDD – Proposed Design Goals • Automated – users should be passive; administrative tasks should be minimized where possible • Efficient – don't want to broadcast • Flexible – need to accommodate a wide variety of use cases • Simple, lightweight to implement and deploy • Leverage standards where possible

14. IDD – Use Case Examples • SMTP-like deployment in clients – port 80 is blocked, users must go through intermediary • Location of nearby surrogates • Intermediary → intermediary configuration (mesh building) • Location of service-specific intermediaries (OPES)

15. IDD - Discovery Issues • Matching boundary of discovery to client deployment • Ease of deployment / implementation • WPAD good for information, but is not a starting point (draft-cooper-webi-wpad-00)

16. IDD - Description Issues • Describing behaviors (fail-over, load balancing, etc.) • Describing locality (clients and intermediary proximity on network) • Determining precedence • Description format – XML?

17. IDD Components

18. IDD - Next Steps • Join WEBI Mailing List – webi-request@lists.equinix.com • Document editors, reviewers, authors – see chairs • Gather requirements from other groups • Need vendor input and participation • First deliverable is requirements document

19. Resource Update Protocol • Background • Scope • Design Goals • Use Cases • Issues • Next Steps

20. RUP - Background • Interest in distributing state/metadata from servers to clients: • DRP (http://www.w3.org/TR/NOTE-drp-19970825.html) • DOCP (http://hpl.hp.com/techreports/1999/HPL-1999-109.html) • WCIP (draft-danli-wrec-wcip-00) • Content Signals (draft-rzewski-cndistcs-00)

21. RUP – Scope Discussion • Protocol in which an entity communicates state/metadata about groups of resources to subscribed clients • Discussion: • Communication predominantly server → client • Describes attributes of multiple resources • May be separated from resource authorities • Authorization / authentication should leverage other work

22. RUP – Proposed Design Goals • Modular, Generic – a standard framework to deploy applications that fit defined scope • Extensible – should be able to be used in unforeseen applications • Leverage existing standards where possible • Simple to implement

23. RUP – Use Case Examples • Cache invalidation • Cache delta update • Cache multiple object update • Processing instructions for surrogates • Client update (search engine, ‘bot, etc.)

24. RUP – Issues • Managing state on servers • Choice of transport • Resource grouping (channel description) • Announcement mechanism(s) • Subscription mechanism(s) • Reliability mechanism(s)

25. RUP Components metadata/state resource selection update message channel reliability subscription announcement … invalidation update / delta XML? application URISpace? XMLProtocol/SOAP? BXXP? framework well- known location … http header

26. RUP - Next Steps • Join WEBI mailing list –webi-request@lists.equinix.com • Document editors, reviewers, authors - see chairs • Gather requirements from other groups • First deliverable is requirements document • Start gathering consensus about approach

27. Conclusions • Review Charter • WEBI mailing list – webi-request@lists.equinix.com • Copies of presentation: • In minutes • At http://www.mnot.net/papers/ietf-49-wrec.{htm|ppt|pdf}