Transcript Document
WREC Working Group WREC Working Group IETF 49, San Diego Mark Nottingham Co-Chairs: Ian Cooper [email protected] [email protected] IETF 49, San Diego WREC Working Group Agenda • • • • • Introduction (2 min) WREC Status (13 min) Intermediary Discovery and Description (20 min) Resource Update Protocol (20 min) Conclusions / Next Steps (5 min) IETF 49, San Diego WREC Working Group WREC Status • • • • • • New Co-Chairs Known-Problems update Taxonomy update WREC wrap-up Motivation for New Work Proposal IETF 49, San Diego WREC Working Group 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) IETF 49, San Diego WREC Working Group 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 IETF 49, San Diego WREC Working Group 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 IETF 49, San Diego WREC Working Group 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 IETF 49, San Diego WREC Working Group 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 IETF 49, San Diego WREC Working Group Intermediary Discovery & Description • • • • • • Background Scope Design Goals Issues – Discovery Issues - Description Next Steps IETF 49, San Diego WREC Working Group 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 IETF 49, San Diego WREC Working Group 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 IETF 49, San Diego WREC Working Group 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 IETF 49, San Diego WREC Working Group 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 IETF 49, San Diego WREC Working Group 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) IETF 49, San Diego WREC Working Group 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) IETF 49, San Diego WREC Working Group IDD - Description Issues • Describing behaviors (fail-over, load balancing, etc.) • Describing locality (clients and intermediary proximity on network) • Determining precedence • Description format – XML? IETF 49, San Diego WREC Working Group IDD Components IETF 49, San Diego WREC Working Group IDD - Next Steps • Join WEBI Mailing List – [email protected] • Document editors, reviewers, authors – see chairs • Gather requirements from other groups • Need vendor input and participation • First deliverable is requirements document IETF 49, San Diego WREC Working Group Resource Update Protocol • • • • • • Background Scope Design Goals Use Cases Issues Next Steps IETF 49, San Diego WREC Working Group 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-1999109.html) – WCIP (draft-danli-wrec-wcip-00) – Content Signals (draft-rzewski-cndistcs-00) IETF 49, San Diego WREC Working Group 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 IETF 49, San Diego WREC Working Group 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 IETF 49, San Diego WREC Working Group RUP – Use Case Examples • • • • • Cache invalidation Cache delta update Cache multiple object update Processing instructions for surrogates Client update (search engine, ‘bot, etc.) IETF 49, San Diego WREC Working Group RUP – Issues • • • • • • Managing state on servers Choice of transport Resource grouping (channel description) Announcement mechanism(s) Subscription mechanism(s) Reliability mechanism(s) IETF 49, San Diego invalidation update / delta … XML? metadata / state framework application WREC Working Group resource selection URISpace? update message XML Protocol / SOAP? channel subscription announcement http header wellknown location … BXXP? reliability RUP Components IETF 49, San Diego WREC Working Group RUP - Next Steps • Join WEBI mailing list – [email protected] • Document editors, reviewers, authors - see chairs • Gather requirements from other groups • First deliverable is requirements document • Start gathering consensus about approach IETF 49, San Diego WREC Working Group Conclusions • Review Charter • WEBI mailing list – [email protected] • Copies of presentation: – In minutes – At http://www.mnot.net/papers/ietf-49-wrec.{htm|ppt|pdf} IETF 49, San Diego