Notes from AAAW

[Lisa Dusseault <[e-mail]>]

Here are the notes from last week's Applications Area Architecture  
Workshop.  The meeting agenda was put together on-the-spot, based on  
the interests and ideas expressed in the position papers.

Agenda summary:

Monday AM: Plenary session, URI Templates presentation, general  
discussion about good and bad reuse.  Chris' framework combining all  
papers into advice for protocol designers.
Monday PM1: 4 breakouts: HTTP Reuse, HTTP Auth, Net&App  
communication, URI templates.
Monday PM2: discussions based on breakout topics, and collectively  
figured out breakout topics for Tuesday.

Tuesday AM: breakouts on HTTP Mail and XML Schema
Tuesday PM1: Localization (Location?) and Identifiers, Push/Pull &  
Notification
Tuesday PM2: Synchronization, Documenting advice and giving pointers  
to Apps Protocol designers

Many thanks to all the participants, for position papers, for notes  
taken (Barry and Leslie, notes inlined below).  Advance thanks to  
those who follow up on their promises to publish I-Ds or take other  
action after the workshop!

----

Monday AM

Plenary session

URI templates explanation and discussion

Joe. URI templates already appear in WSDL, one paragraph in it.   
Substitution rules should be complex enough to do what you want to  
do, but not Turing-complete; implementable but rich.

Mark. URI templates very useful in figuring out "Here is where to go  
once we have more information" -- the username, etc.  Template  
variable names might need to be standardized across sites???

Leslie, Mark. This, like anything, can be abused.  How much effort  
should we put into applicability statements and preventing people  
from using in ways we don't like?

Mark. Tangent about the Prefer header proposal by James Snell --  
intended to provide clients a way to ask what kind of response they  
want particularly in the case of a new resource submission.  How  
would we steer people to solve this, a general-purpose solution or not?

Ted: Semantics are about meaning.  Unless the original intended  
meaning constrains what you can express, the original intention does  
not prevent future users from expressing something completely  
different. Do we provide building blocks that are restricted, or do  
we provide building blocks that people can drop on their feet?

Pete: Reuse is about neat syntax.

Larry: Protocol design is not just about syntax, it's about semantics  
too. But you provide as little possible semantics to a neat syntax.   
The design goal is to not add so little semantics that you can't use  
it, but to add just enough.

John: Whether we intend reuse or not, things leak all over the  
place.  We can end up with constructions that are utterly  
uninterpretable.  It's happened with HTTP URLs -- does it mean you go  
to a Web page and look at it, or is it a token you can use in your  
application to mean something?

Ted: W3C's complaint last week was about people using too much  
bandwidth looking up HTTP URLs that weren't supposed to be  
dereferenceable!  They realized this accidental dereferencing costs  
them real money.  HTTP is classic for this. The host header: before  
the Host header was introduced we exhausted the IP address space at a  
ridiculous rate.  What the IETF adds to application design is to do  
cross-area review and say "this is the result of your design".  If  
you try to write guidance to prevent people from saying what they  
want to say and can say with a syntax, you are lost.  In fact even if  
the syntax can only sort of say what they want to say, they will find  
a way to say it.

Templating is a wonderful problem for this. There's a whole skein of  
problems I'd like to knit into nice solutions. [Knitting analogy was  
noted and appreciated by knitters present]

Barry: A perennial thing in IMAP is using folders for actions: a Sent  
folder, a Deleted folder.  They found ways to do what they wanted to  
do even though the standard didn't do it for them.

Larry: We do need to look at what went wrong in the past.

Ted: People coming to the problem space later do not see things in  
the same terms as the people who built the protocol.  What barry  
said, The people who really felt they needed to do something invented  
all kinds of bad ways of getting that done.

Pete: The people who invent their own crap are limited in the bad  
they cause.  It's worse when we endorse something bad.  [Ted: Our  
endorsement is useless.]  When we shoot ourselves in the foot -- IDN  
is a lovely example -- we do much more damage to ourselves.

John: IDN is a good example. The new proposal says that if you  
encounter the following bad things when finding a label in the  
client, you SHOULD NOT look it up in the DNS.

Pete: In the case of IDN we've left the syntax the same and pumped up  
the limitations on the semantics.  We try to arrange it to cause  
damage to the people who try to do bad things, not damage to everybody.

Ted: You said that IMAP folder abusers didn't win because they  
couldn't interoperate. If they'd only written it down in a spec they  
would have won, it would have been easy to interoperate.

Chris: Sometimes you add requirements that the server MUST reject  
something, and that can limit abuse.

Larry: Why HTTP Authentication didn't work very well.  It was kind of  
out of scope to bring into the HTTP Auth spec the details about what  
the user interaction would be.  Independently of the flaws of the  
protocol itself, one of the reasons things didn't get adopted was  
because the WG couldn't talk about UI.

Chris.  That's a common problem and I push against that when I can.   
It's not viable to push back against HTTP form-based auth over TLS,  
because any replacement is not viable unless it has some level of  
branding and layout support for the dialog.  It doesn't have to be  
full JavaScript widgets, but something.

Larry.  The folks with the expertise in what level of control they  
need in the UI don't come to IETF meetings, and the expertise isn't  
here.

Mark.  IETF folk don't realize why Web sites like using cookies and  
forms, not just for the UI but also for how crypto happens.  Even if  
Digest Auth met my UI requirements, I'd need to trust the  
implementations of Digest.  Whereas if I use cookies I can design my  
own little protocol using token exchange.

Lisa: Pulling topic back to URI Templates.

Cullen: URI Templates look great, my interest is of course in  
extending it!  I think there may be a lot of theory under the name of  
string rewriting.  It may not be useful to you.

Mark: We talked about managing extensibility.  What is IETF policy?

Rohan: the policy is a mess?

Lisa: Isn't the policy case-by-case, and how would we do otherwise?

Joe: OAuth is getting much take-up outside the IETF.

Nico: If you're going to do Authentication, you're also going to do  
session crypto. my pp touches on Cookies, but treats them as inevitable.

Rohan: is there any reason why browsers couldn't go and do what you  
suggest doing today?  [Nico: no]  So there's no protocol work there,  
there's only evangelism.

Nico: Cookies are a mechanism we use to tie session crypto, that's at  
a layer below the application.  If you want to get rid of cookies, do  
crypto at the App layer.  I don't think that's going to happen, so I  
think we're stuck with cookies forever.   What's wrong with cookies?

Lisa: Yngve's I-Ds explain some problems with cookies and present  
some solutions but there's never been much uptake or support for his  
I-Ds.  You all should read them.

John: Should somebody sit down with Yngve and do a Working Group  
proposal?

Lisa: There's also the HTTP WG which Mark chairs.

Yves: It's already hard to find people motivated enough to do work in  
the HTTP WG.

Larry: We have the topic here about cookies but it's also about  
reusing authentication methods.  The Liberty Alliance, I wonder if we  
step back from HTTP Auth to what is our general approach, that might  
not have much to do with cookies.

Lisa: I'll step out on a limb here and say this is pretty  
political... There's Liberty Alliance proposal, OAuth, Kerberos  
proposals, Client certs in TLS.  Nothing solves every problem.   What  
can we accomplish in this workshop?  I want to uplevel and discuss  
this only in the context of what should be the agenda or work item  
that would be good for this workshop?

Cullen:  If this group can do something about browser UIs for  
authentication, this would be good work.

Mark: One of the outputs of a Bar BOF in Vancouver was to start work  
on another workshop specifically on that topic.  We've had this  
discussion in a number of fora and we can't do it here effectively.

Nico: I'm loathe to see Apps people say that security isn't our area  
of expertise and we can't talk about it. You know the result of that.

Lisa: There's a W3C WG on Usable Auth, that's exactly what Cullen  
asked for as a group focus.  Is anybody here part of that W3C WG?   
[there was nobody]

Joe presented examples and use cases for URI Templates.

Jeff explained need for a general reference for how to check server  
identity in certificates. Right now some specs reference 2818, some  
specs reference 4513, some specs reference 2830.  It's more work than  
just cut-and-paste; there needs to be some real work and thought on  
this.  Should we include, what happens to your authentication state  
when you stop and start TLS.  LDAP had a lot of discussion how to do  
this right for LDAP, but it might not be right for other  
applications.  Let's start with the server identity stuff, and the  
other stuff might be another spec.

Larry: Are we not doing enough diligence in reviewing documents to  
see that they're doing all these references and inclusions and  
updates correctly?

Chris presented a framework for all the PPs about reuse, and pointed  
out how this could be an outline for a general paper on Apps protocol  
design.

----

Monday PM1

HTTP Reuse: report after breakout

Lisa: In discussing HTTP re-use, we broke applications we might  
advise into three different groups. This is clearer than BCP56's  
targeting.  Some applications extend the functionality of HTTP for  
existing resources, and advice to those designers is probably very  
case-dependent.  Some protocols borrow HTTP syntax and again that's  
probably very case dependent.  What we might consider is advice for  
protocols that tunnel over HTTP, that may define limited-use  
application-specific resources or not define resources at all.   
However, we don't seem to have consensus on what kind of advice to  
offer those applications except that to admit that the port- 
definition advice in BCP56 is clearly being ignored.  We don't have a  
common model on the drawbacks of defining new methods, or even on the  
necessity of flagging the existence of a new protocol by any means.   
How do we decide how much advice, if any, to give to people using HTTP?

Yves is likely to try to write an I-D, and drag Thomas (not present)  
into it.  Maybe it can obsolete BCP56 or update the part that makes  
port number use recommendations that everybody ignores.

Network and Apps: report after breakout

Ted: Summarized a wide-ranging discussion on the network, transport  
protocols and apps.  Added the application *semantics* layer, which  
is really what users are interested in, and this is different even  
from the application *protocol* layer.  We discussed how a layer  
violation is a layer transmission that is unexpected.  We discussed  
how applications really can't ignore what the application protocol  
syntax is, can't even ignore whether TCP or UDP is being used.   
Packet loss rates affect high-level choices.  Even whether you're  
using 802.11 or Ethernet affects threat models.  In actual  
deployments, we have a bunch of protocols that deeply understand  
semantics like "hypertext" but that immediately got adopted by many  
other semantics.  We should look forward to XMPP being used by many  
things other than IM and buddy list.

Ted offers a question for the ADs that follow him; Does the APps area  
look for new work which is new building blocks that applications  
might make use of, or do they look for new applications and count on  
designing the pieces those applications need?  Ted believes the  
building block work can happen but it doesn't usually succeed in  
deployment without a driving need, and BEEP is an example of that.

HTTP Authentication: Notes by Barry

-----------------------------------------------------------
Breakout on HTTP authentication
(Barry, Chris, Nico, Mark, Tony, Kurt, Jeff)

Issue: develop HTTP authentication protocol that
1. reduces phishing, and
2. is likely to be deployed.

Simplifying assumption: initial enrollment is a harder problem, is  
less susceptible to phishing, and won't be considered here.

What to do:
1. Develop an authorization framework such that:
a. No identifier/password is transmitted, even over TLS.

b. Using (a), eliminate the need for a user to enter a password in an  
HTML form.  Users would be taught to enter passwords only in the  
password-entry widget (java or activex, say).  "80%" solution.

c. Use an auth mechanism (such as public key method) that makes a  
password useful only locally (password to the local keychain, for  
instance).  Exposure of the password to the bad guys no longer  
matters, even if they convince the user to do it.  "95%" solution.

2. Firefox is a good starting point.  Make a Firefox extension  
prototype a prereq for real work here.  FF extension can "discourage"  
entry of passwords into HTTP forms, to enhance the effectiveness of  
1b, above.

3. Get input about requirements, from "real" phishing targets.
- Engage APWG?
- Mark tells of possible workshop coming from Vancouver bar BOF.
- Klensin notes that talking to banks and such is useless.  Suggests  
engaging congress (senior staffer to chair of House Banking  
Committee, for instance).

Notes about the framework:
1. Write XML HTTP req with channel binding
2. Write javascript bindings to SASL

UI notes:
1. "Directed identities" built into the browser -- browser strongly  
discourages user from using "boa.com" identity for "b0a.com" or "boa- 
login.com" web site.

2. Discussion of colour cues and other OK/warning mechanisms.  Note  
that anything that will work has to be VERY hard to miss or  
misunderstand.  Note also that most have accessibility (a11y?) issues.

-----------------------------------------------------------


Monday PM2: used in reporting back from breakouts, and to figure out  
breakout topics for Tuesday

-----

Tuesday AM

XML Schema

Rohan's response to request for notes: "Ugh"

Email architecture and HTTPMail: Notes by Leslie

------------------------------------------------------------------------ 
----
Random question -- is it the case that we already have more e-mail  
retrieved over HTTP than by IMAP?

Mailbox is a uniform store; no hierarchy or imposed structure. Why  
another protocol?

Pete responds -- HTTP is not being used to retrieve e-mail; it is  
being used to *view* e-mail.  Many services use IMAP to retrieve the  
e-mail that is presented over HTTP.  Chris & Lisa elaborate -- there  
is a 3rd piece of the puzzle, eg using AJAX to build the interface  
between IMAP and the viewed e-mail front end in HTML.

Pete is comfortable with this being a back-end protocol.  Believes  
that things like GMail are doing stuff more like this than like IMAP  
-- i.e., a unified store with no particular structure enforced on it.

Lemonade "happened". We've suffered through IMAP to try to get things  
to work with small devices -- need to take a step back and develop  
something that will inherently be used with different devices.

Leslie -- well, what are the things that need standardization in  
order to make a uniform experience across e-mail instances.

Lisa -- need to have URIs for all messages in the store; standardized  
set of retrieval expectations (e.g., by time received, etc).

Agree -- one of IMAP's limitations is the set of properties is fixed  
(and only extensible with x- headers).  So, it would be interesting  
to have  the ability to add to the list -- clients or servers or  
both?  Are they immutable (whether set by client or by server?).   
E.g., timestamps should not be changed by the client, because it will  
screw up synchronization of other clients accessing the same store.

Revisiting the existing distinction between message headers and  
message delivery headers.  (E.g., received-by).

Pete wants to make an architectural separation between properties  
that are immutable or user-adjustable.  Lisa asks why?  Immutable  
attributes are part of the message object; others can be part of the  
metadata associated with the message. Lisa argues that that  
separation is real (what is message, what is metadata) but is not  
necessarily aligned with the immutable/not distinction.

John suggests that there are 3 categories:  1/ if the mailbox is  
public there is set stuff everyone can see; 2/ the client can set  
properties that it expects no one else to see; 3/ things that the  
client can set but others may see (which brings up the whole issue of  
ACLs).

Next issue is the question of "what do you download".  What do you  
want/expect to be able to download in a single transaction? (I.e.,  
"just" the message, or message with what attributes?).  Comparison is  
drawn to ATOM -- where, for example, it is asserted that the client  
cannot "trust" that the server has offered the entire body of the  
entry.  While the trust model between mail client and server provider  
is more direct (than with ATOM feeds), the same situation is likely  
to apply -- the server may elect not to offer the entire message body  
if there is need to allow servers to optimize for (perceived)  
conditions -- e.g., dealing with small devices, etc.

Chris asks -- does this mean breaking open RFC2822?  Pete describes  
alternative for co-existence going forward -- getting stuff into and  
out of this format from 2822 format.   What about submission?  Handle  
same way as lemonade:  store the message and use a trigger to get an  
SMTP server to take it and ship it.  Pete believes both delivery and  
submission will be clients of the access protocol.

Lisa suggests a strawman:  accept reality and deal with metadata the  
way applications do, by changing the URL -- adding specifiers for the  
part of the object you are after (body, metadata, plaintext).    This  
allows for
caching the explicit results. Pushback on this as a kludge. Though  
Pete allows that an HTTP front end on this could allow for different  
command data and results in different URLs.

 From experience in managing very large scale deployed bases, Chris  
offers that what you want is to have a highly stable, immutable data  
store backend.  Where you want to do the munging & servicing is at  
the access layer of boxen.  Joe offers that Google does _not_ have  
that experience.  Google does not have a single high-availability,  
high coherency big iron back end.  Instead, it has a table and a  
honking great distributed file system.  Pete counters that this  
doesn't take away from the point that you want to do the processing  
at the outside edge.

Chris -- 4 types of IMAP state.  1/ security layer (tls) IMAP state.  
2/ authentication state 2/ current selected mailbox (a big part of  
IMAP state; goes away in Pete's architecture) 4/ state related to  
keeping a mobile state in sync with a server. Chris thinks this is  
important to keep; it's very useful. Cullen -- yes, you want a pub/ 
sub structure.

Leslie steps back and asks -- what is the big win with moving to  
this?  Pete's answer -- we have a long (and growing) list of things  
we cannot do with the current architecture.  So, this is throwing the  
baby away with the bathwater.  It'll be a step back in order to step  
forward successfully.  The concern is that this step back will be a  
death knell to the whole idea.  GMail is already an evolutionary  
competitor -- that's what people will use.

Lisa's interest in this is for "e-mail mashups", and other innovative  
uses of messaging.

A lot of concerns about feasibility -- does this solve enough  
problems that it will actually be taken up?    See note above about  
GMail solving the webmail problem.  Not clear that finding device  
manufactures to implement this would actually produce the desired  
result?  Just running forward with this will run into the same  
problem as BEEP -- without a driving application, this will be  
developed and delivered in a vacuum.

Cullen offers -- if you can't do integration with Exchange, you're  
dead in the water.  It's observed that just requires there is a  
"this" <-> MAPI interface, implemented by MS or other.

Pete comes back to the issue:  this is a desired architectural  
upgrade to be able to address existing limitations in IMAP that will  
go nowhere unless there is someone willing to implement. Lisa pushes  
back -- she would like to see a very preliminary protocol (with  
implementation?) to demonstrate the specific directions and stir the  
imagination of potential implementers (of webmail services). "Oh, I  
can do <this> with this!". (Ties into Tony Hansen's position paper on  
extreme protocol development?).  Nico -- would like to see a bit of  
text about the limitations of IMAP and the philosophy of the  
architecture in the documentation as well.

Chris asks -- what are the minimum changes to IMAP needed in order to  
be able to achieve the desired architecture?  E.g., you need an  
identifier that doesn't change irrespective of messages moving.   
Because they will still move -- either because people are using  
(traditional) IMAP clients against the message store or simply  
because people still want to user their existing message repositories  
and want to be able to what the data store does to the message.  For  
example, you need to be able to tag messages to be in particular  
groups, which corresponds to today's (implementation of) filing  
messages in separate folders:  need to be able to recreate something  
like folders.

Threads across multiple accounts; threads across information stores  
(e.g., e-mail, blogs) would be useful.  Need to think about  
integrating this in a broader sense of workflow.  There _is_ general  
frustration with the lack of integration of e-mail with other  
activities -- e.g., bringing messages into other applications that  
are being used to carry out a given task.  This is accessing your  
message store from other applications. Or, assigning a message to  
another recipient (owner).  Pete observes that he explicitly stayed  
away from that whole concept in his draft.

At some point, we are really talking about a generalized document (or  
object) store -- what would we like to do with all of your files, for  
example? As part of your workflow.

So, the path forward might be to work with an IMAP server software  
developer to provide an implementation that integrates access using  
this model with their IMAP service.  Then the client development  
becomes less instantly critical and can evolve to take advantage of  
the expanded functionality.
------------------------------------------------------------------------ 
----

----


Tuesday PM1

Breakout: Localization (Location?) and Identifiers

Led by Ted

1.  DNS is not great for anything but network-facing resources. It's  
not a good way to look up pizza delivery services.
2.  Would a directory above DNS help with the use cases?

Breakout: Push/Pull, Notification

HTTP is good for pull.  HTTP-based systems need a simple way to  
push.  COMET? Long poll or infinite response?  Will anybody implement  
another protocol besides HTTP?  We discussed browsers' focus on HTTP  
exclusively.

How do we get the word out?  Yves will see if the W3C mobile  
interests WG is interested in hearing about this; maybe mobile  
clients are a real consumer for this so that a mobile device's server  
can be their notifications aggregator.

One missing building block is the binding between HTTP resources and  
the place where you can get notifications.  One might be interested  
in a single HTTP resource (e.g. a feed, a front page) or a family of  
resources (e.g. a photo album online).  THe binding for both Atom and  
HTTP could be Link Relations: the server would advertise the related  
notification resource either in the link relation of the Atom Feed  
document, or in the Link response header with the same type.

We had a good discussion of the security implications of putting any  
content in notifications.

----

Tuesday PM2

Breakout: Synchronization

Although there's years of work, thousands of PhDs and many solutions  
on Synch, we still have real user problems.  The one Cullen was most  
concerned about when he wrote his PP is the personal Address Book  
problem.  It's just one person's data, and yet it can't get  
synchronized properly between phones, cars, and multiple laptops.

We realize that conflict resolution is deeply dependent on the  
application semantic: it may be fine to synchronize a change to one  
attendee's status and a change to another attendee's status by  
applying both changes even if they were made by different people; but  
a change to location and to host of an event might not be applied  
together.

Can we separate the semantics and conflict resolution from the  
transport of changes and change metadata?  What change metadata is  
required (timestamps, time intervals, user identification)?

We talked about how atomicity is also application semantic dependent,  
and how we need a number of UUIDs for atomic objects, devices,  
perhaps even changes or change sets.


Breakout: Application Protocol Guide

When people consider solving certain problems in application  
protocols they can find a lot of prior art:
- application bootstrapping, how to find your app server
- application configuration, how to set up your client
- Protocol substrates and how to use them
- Data encoding
- Authentication, encryption, session state
- i18n
- URN/URI use
- Schemas and XML use
- Extensibility, capability advertisement and negotiation
- Registration and naming issues
- Modular design

Chris & his breakout group gathered many pointers of good and bad  
examples of design in these categories.  Sometimes we can point to  
other BCPs, sometimes the advice and pointers we can give are not yet  
gathered any place.

Wrap-up: Thanks to host Google for hosting and CommerceNet for dinner.