2.1.1 Applications Open Area Meeting (apparea)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-07


Keith Moore <moore@cs.utk.edu>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor:

Scott Hollenbeck <sah@428cobrajet.net>

Mailing Lists:

General Discussion:
To Subscribe:

Description of Working Group:

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

ggm: agenda: WG/BOF status (10m) New WG/BOFs (40m) Charter updates (20m) Cross Area Tech Topix (20m) Open Mike (1h or to close)
ggm: more stuff to come in open mike.
ggm: WG/BOF status.
ggm: closed: CALSH, IMPP, IPP, MARID, MSGTRK, XMPP. mostly closed for charter completion. some with malice [laughter]
ggm: new: SIEVE, BoF this week,being run as active WG already. IESG telechat for approval coming up.
warlord entered the room.
hartmans entered the room.
ggm: Charter updates: OPES. (will be on agenda)
ggm: interesting things this week. Kitten (GSSAPI update). security focus
ggm: Almost BOFs: PERM, MASS, RFID. PERM/MASS met in S.D. scheduled to meet this week, pulled out when not ready enough. try again,
ggm: CALSIFY is also on list.
ggm: RFID, about reader protocol. no drafts, vague ideas, some conflicts with other standards bodies. pushed back. maybe meet as bof next time.
ggm: Crocker: list CLEAR. combo of CSV from MARID, stuff not a good fit in MASS.
ggm: [speaker is Scott Hollenbeck btw]
ggm: New WGs.
ggm: Sieve, Mail filtering . proposed chairs are cyrus, alexey.
ggm: IDN with EPP, IDNPROV. Edmon, Howard to chair
ggm: Charter Updates.
ggm: OPES. Tony (new co-chair) to talk.
ggm: chartered originally in 2002, framework for callout services via standard mechanism. focus on HTTP (eg web cache calling out to virus scanner)
resnick entered the room.
ggm: 7 RFCs published. based on OCP core, agnostic on protocols, app profiles specify how to deal with (HTTP, FTP, RTP, SMTP...)
ggm: Dave Crocker asks tricky question about layering/profiles.
ggm: Experience with HTTP?
ggm: Tony: webcasters using it. can't answer in detail
ggm: Proposed re-charter:
ggm: stable after discussions, focused, narrow. similar work to HTTP protocols, servers, but for SMTP.
ggm: doing scenarios, use-cases. discussing 'rules language', relationship with SIEVE
ggm: example use case is to make virus scanner from web cache now also available as callout service to mail via SMTP
brabson entered the room.
ggm: Pete Resnick: pragmatic question. Do folks in eg sendmail camp want to use this?
ggm: [yes]
ggm: Pete so at least some folks want to write to this as an API/Protocol.
mrose left the room.
yushunwa entered the room.
ggm: Yes. people have investments offsite, want to shove different things to it eg centralized virus scanning. firewalls do this.
randy entered the room.
ray_atarashi entered the room.
ggm: reference to 3238. big discussion in chartering, could be used for nasty things like censorware. is using virus scanning just polite window-dressing?
brabson left the room (Disconnected).
ggm: discussion says yes, and then again no.
ggm: [nobody is saying who they are, so a bunch of stuff is unattributed. sorry. -ggm]
ray_atarashi left the room.
ggm: Done.
ray_atarashi entered the room.
resnick left the room.
ggm: Cyrus on SIEVE (co chair)
resnick entered the room.
ggm: ad-hoc, non WG mode, but produced several RFCs. extensions, 8-10 drafts 'out there' need to progress.
ggm: main goal, take SIEVE to DS. look at revising base spec in light of bugs, no major changes
ggm: [end]
brabson entered the room.
ggm: Edmond on IDN/EPP. now IDNs starting to be deployed, need domain registration support.
ggm: so this addresses client to registry processes
brabson left the room (Disconnected).
ggm: Hoffman: you need to consider stds track doc to cover changes to EPP. normative pointing to non-stds .. problem
ggm: Edmon need to specify way to pass IDN critical data.
ggm: Ted: eg particular registry may just not do this, but may ignore tags passed in. Hope we're aiming for different XML objects, extension objects
kivinen entered the room.
ggm: Klensin: good to do this properly
leifj left the room.
amelnikov entered the room.
ggm: Erik Nordmark on Multi6 app referral. draft is findable on the -nordmark- string I guess (he took the URL off before I got there)
resnick: draft-nordmark-multi6dt-refer-00.txt
ggm: talks about background, scaleable V6 site multihoming goals -keep the socket API stable. looking at L3 shim. app issues are not approach specific
resnick left the room (Disconnected).
ggm: solution space may include 'do nothing' -worrying at connection establishment, (transp proto, apps figure out set of addresses) -multiple locators, sublayer in stack to make transp. survivable, introducing new id namespace with distributed mapping system to locators
resnick entered the room.
ggm: implications.
ggm: apps have to see a 128 bit value. trying to distinguish from locators, can be multiple locators. can be one of them, or something not reachable. not central to discussion.
ggm: key issue is how to deal with this thing, not its routing behaviour.
ggm: sockets API, need something 'new' in the stack to map to locators
ggm: likely outcomes
ggm: defining namespaces, deploy takes time. can use DNS, AAAA/PTR recs. imply hierarchical allocation. thats what DNS admin deals with.
ggm: hard to get consensus this is THE way to do multihoming.
ggm: short to medium term, multiple locators without new ID namespace is likely. -people want a free lunch
ggm: good news: no changes to apps which use IP addr as 'short term' handle.
ggm: take getaddrinfo() and pass to connect() or sendto()
ggm: other apps usages. -retaining handles for longterm use, callback features, referral via 3rd parties, ID comparison
ggm: issues already, not secure, already using 'higher level' identifiers
ggm: approaches:
ggm: use FQDN wherever possible. at least get lookup abstraction. not always appropriate.
cnewman entered the room.
ggm: can use single IP address. still works but has no redundancy benefits
ggm: apps may have to hold/store sets of locators, ULID/identifiers, deal directly
ggm: Issues (seeking feedback)
ggm: 'just use FQDNs' ?
ggm: URI form?
ggm: hard to get accurate FQDN. PTR lookups often wrong.
ggm: Ted: from app perspective, what are the advantages of multihoming? money benefits to org (use cheapest link, failover) real benefits to org, but from app perspective, if no difference between identifiers, both reachable, speed/quality the same, shouldn't care which one I use
ggm: looking for here, how is the app going to know not just there are multiple locaters, but how to exploit them
ggm: Brian C. cochair Multi6. analogy to problems already have. if have 4 and 6 address for FQDN, which to use? already have this problem.
ggm: whatever you do is wrong. send FQDN to other people, may not resolve correctly. send one of the locaters, may not be best at the other end.
ggm: current apps do bad job of dealing with this.
ggm: Erik. if app going to deal with this, need API.
ggm: Dave Crocker. spent energy on this both for multi-homing, mobility.
ggm: not at all clear, what problem being solved for applications. applications are consumer of this. not sure folks working on this have basis for making decisions
ggm: Erik: yes, its a problem.
ggm: Dave want to highlight problem
amarine entered the room.
jaltman entered the room.
ggm: [unnamed person] solve at connect setup time, higher level API needed. 'connect by name' abstraction needed all the time, to get away from transport choices.
ggm: Erik middleware has this kind of thing already
ggm: [unnamed person] SCTP has one approach. session can persist
kivinen left the room.
ggm: Ted. wondering if fundamental presumption, if reachable to eg randy via qualcomm VPN, then cannot ever refer to this to outside, since not workable in global net. knowing reachability, hard. apps need to know. not all equivalent. have to iterate, not select (may pick wrong one)
cnewman: [unnamed person] = me (Chris Newman)
ggm: Erik eg globally unique v6 addrs, but not globally reachable. host can look at upper bits.
ggm: [another unnamed person] who does the iteration to determine locator to use.
ggm: at least 3 different solutions being considered, considering contradictory requirements. going to need to make tradeoffs/decisions.
ggm: William Liebzon. highlight diff multi6/HIP people work. differences layerwise, for apps.
fenton: Last unnamed person was Eliot Lear
ggm: Erik. using 128 non-reachable 'upper layer identifiers' statistically unique, make them up on the fly if you like. thats one aspect of HIP.
Glenn Parsons left the room (Disconnected).
ggm: lookup service to submit one, ask 'tell me about its locators'
ggm: HIP has protocols to do exchanges, security, lookup service on flat space of hashes of public keys is challenging.
ggm: William. both trying to create 128bit locater, 'virtual IP address' to pass to app
ggm: Erik yes, HIP+lookup service if/when do this, don't have to worry about set of locaters. promotes transparency, done by underneath layers. even if try doing this, will take long time to get there, scaling issues. even if HIP gets deployed on large scale need to deal with passing lists of locaters, in addition to HIP id.
ggm: William. app keeps address, is that how you want it?
ggm: Erik take offline
ggm: [yet another unnamed person] brian c said something striking. already multihomed, if 4 and 6. scope has to include case of single i/f but with 2 bindings
ggm: Erik in abstract yes, thats the case
tonyhansen: [unnamed => larry masinter]
ggm: [pekka nickander] workshop Saturday on HIP, related architectures. came to conclusion, value to add layer to IP stack, lowest layer with location independent id's. HIP doing that, but also doing more. since HIP doing more, value to have two protocols, analogous to TCP and UDP split. one can be HIP providing eg also security, but also maybe something else, multi6? works without external infrastructure, security. these were wkshop conclusions
ggm: Christian Huitema. amazed when new proposal 'makes things simpler'
ggm: really, when make something new, have to handle new AND old. doesn't make simpler
ggm: Erik agree. doesn't make simpler
ggm: Christian been looking at this a lot in Microsoft. some things use higher level APIs. don't care. some which do care, already handle eg IM, Mail apps don't see value in this, making things too complex.
ggm: Erik don't see value in multi6? thats a discussion for multi6.
ggm: Christian, but applications people write their own shim layers.
ggm: Erik but is it valuable to apps not to have things break?
ggm: Christian have to be backwards compat, have to support breakage anyway.
ggm: Eliot in short term, transition issue
ggm: Christian short term not short.
ggm: John Klensin. wish to avoid 'death of internet' but this is one of them.
ggm: hourglass model got us to where we are. magic happens 'down in other side of narrow waist of hourglass'
ggm: following on Christian, move into world, tell app 'need to understand topology, different modes, ways to get out' then we will kill the important thing. in process, will do something else. suggest multi6, including successor AD directors need to think about carefully. way moving, selling V6, multihoming
ggm: if end up giving away multihoming, nets, smaller than PI space from registries will kill v6. few real motivations other than running out of address spaces, believe have already run out in some sense. telling apps to know topology of net, kills the goal.
ggm: Erik just want to carry variable length sets of things, not fixed things
ggm: John fine, HIP does that, but having to get into business of what they mean, how to manipulate, subtext of number of proposals, deadly.
ggm: Pete Resnick. to disagree with Christian, yes, lots of apps work around persistent connects with own shim. lots fail and expect user to start over. continue to be lots of those app layer protocols. this makes life easier for upper layer so long as johns warnings heeded. 'thing to pass to get to endpoint, don't worry about dots"
ggm: Ted thanks to Erik [applause]
  * Multi6 application referral issues, Erik Nordmark (submitted by Kurt Erik Lindqvist)
     - Background is to do scalable multihoming for IPv6. Dumping the
       problem into the routing system will not be scalable.
     - Site connected to multiple ISPs. Each ISP will provide a prefix.
     - Keep the IPv6 socket API stable. The API will be fed something
       that will look like a 128-bit IPv6 address.
     - The Design-team have been looking at a shim-layer. The problem
       remain the same no matter at what layer we introduce the shim.
     - Possible solution approaches
       Do nothing
       Only worry about the problem during connection establishment;
       Choose a working locator pair
       Introduce multiple locators and a sub-layer in the stack which
       will make transport communication survive by being able to
    - Implications, the application will only see a
      128-quantifier. The identifier. Called ULID
    - The ULID could be one of the locators, or it could be something
      that isn't reachable. Key point is not if the ULID is actually
      reachable, but weather we need multiple ULIDs.
    - Likely outcome: A new identifier name-space would either take a
      long time to deploy (registry, fees etc) OR use the DNS AAAA and
      PTR records. The last implies a hierarchical name-space, i.e
    - Good news is that this does not change the API. getnameinfo does
      not change. DNS lookups remains the same.
    - Possible approaches, instead of using lists of addresses, use
      FQDN. But that is not a universal solution. Use a single IP
      address. Looking for feedback.
    - ??: There are changes to how IPv6 address are represented in a
    - Ted Hardie: Question from a higher-level perspective what is the target
      for multihoming. From an application perspective, if there is
      not difference between two identifiers, they are working,
      reachable, the applications should not care which one it
      picks. It's when they are not the same the application needs to
      able to pick one of them.
    - Erik: What we have looked at is when one ID fails. The
      application should not have to care, that is up to lower-layers
      to handle and present a stable view to the application.
    - Brian Carpenter: There is an analogy to a problem we already
      have. If you have one IPv4 and Ipv6 address for a single
      name. Which one should you use? If you want to do referral in a
      p2p application you don't really know which to pick or
      send. Multi6 is not a new problem, the same problem occurs
      otherwise as well. Multi6 might be pushing the problem. We still
      don't know what will happen in the multi6 WG, but this is the
      most likely path forward, and the applications will have to deal
      with it.
    - There might be a need for a new socket API call to return the
      set of locators for the local and remote end.
    - Dave Crocker: Have spent sometime on this topic for both
      multihoming and mobility. Listening to this I am not clear what
      problem this solves for applications. Applications are the users
      of this layer and service. How could multi6 make decisions for
      what the application layer needs.
    - Erik: We are using divide and concur and I am here to get this
    - Dave Crocker: Applications only want higher reliability of the
      underlying layers.
    - ??: You might want to look at higher level APIs.
    - Ted Hardie: Is there a fundamental assumption that because A and
      B can setup communication with one set of source locators, A and
      C can use the same source locators. That might not the be the
      case when VPNs are in use. How do I know this and verify this.
    - ??: Do you want to tackle this at the application or the
      Internet layer. The application really only needs one address to
      bind to.
    - Eliot: The teams really need to work together. There are several
      approaches and we don't really know which way we are going. We
      need to do engineering decisions.
    - ??: What is the differences to HIP?
    - Erik: ...
    - ??: The scope of the application protocol that deals with
    - Pekka Nikkander: We had a workshop on Saturday, and concluded
      that there is a need for a layer where
    - Christian Huitema: I am always amazed when we get something that
      is supposed to make it simpler. This does not makes thing
    - ERik: multi6 does not make life simpler
    - Christian: There are two types of applications, does that don't
      care about addresses at all and use APIs. And those that do, and
      they already know how to handle multiple addresses. The
      applications already have their own "shim layer".
    - John Klensin: I usually try to avoid death-at-11 talks. We are
      where we are because the hour glass is as it is. Apps make a
      call and magic happens. If we move into a world where we say
      that the apps needs to understand the topology, we are moving to
      where this goes somewhere else. We are asking more of the
      applications than they can. If this is the request we will kill
    - Erik: No one is asking this of apps. We are trying to avoid this.
    - John: But you are asking the apps to eventually handles various
    - Pete Resnick: Yes, there are many apps that handle their own
      shim, but there are also quite a few that do this with breaking
      the connection. Johns warnings has to be heeded.

brabson entered the room.
ggm: tomorrow, 9am, this room, second session Wednesday
ggm: Scott does blue sheet fascism
ggm: please send presentation materials to Scott H to get into proceedings
ggm: Open Mike.
ggm: Chris Newman draft on 'comparator' in i8n. do once, not every app doing different approaches. came out of IMAP-EXT, sort/thread. want to generalize
ggm: eg use in SIEVE, WEBDAV, w3c protocols
ggm: seeking review from community, naming conventions. looking for volunteer from SIEVE/WEBDAV communities to do detailed reviews, make sure useful
ggm: Juta? puts hand up from SIEVE.
ggm: could be useful offline, cache information, label collation, implementation in client matching label, can use offline.
ggm: [yet another unnamed person] I'll read it.
ggm: Scott. doing i8n comparisons, not addressing topic, going to point to this.
ggm: [q] Chinese/Taiwanese comparators?
ggm: John K remind me, I will get into this can of worms
ggm: idea is to keep abstraction, refer to UNICODE/ISO stuff
resnick: (I think he offered to find people to get into this can of worms. ;)
ggm: John K. have problem with email addresses. want names LHS to be IDN. (in LHS@RHS) efforts to do this got lost in the weeds.
ggm: from standpoint of more extreme ends of i8n community, the differing Chinese stuff, wg process was too chaotic, s/n noise bad, deterministic pronouncements from people with opinions but no knowledge too high. to avoid that problem, do something more focused, with people with expertise., Paul Hoffman started ML process to get proposal to IETF. seemed to work for while, but also collapsed due to differences on how to do this. same people couldn't participate for similar problems which killed IDN.
ggm: in process of thrashing, looking for quick/good fix to exit. not finding any. but community is going to move to non-interop proposals of their own. either inside or outside of IETF
ggm: r[?Larry Masinter? ] report on URI revision issues. v6 link local addresses, going to spin off separate draft
ggm: drafts being proposed, Paul H simpler, radically different. want discussion. schemes from 1738, URI schemes seeking to obsolete the document, 6-7 drafts on schemes, in different states of discussion. would benefit from review. discussion on updating mailto: for i8n
ggm: all drafts individual submissions. draft hoffman, draft hansen. need webpage to point to them.
ggm: [?] implementation survey?
ggm: larry discussion on URI list generally from people with experience. eg found ftp: URI not following draft
ggm: Paul Hoffman. apps area list active enough to use?
ggm: is there apps area web page? better holder of gang of URIs for a while?
ggm: Scott. me? apps ML for discussion. need to promote. Ted and I are in some discussions about website
ggm: Larry; take individ. submissions being watched by AD, or think are subject to IETF review but not in WG, list them there.
ggm: Paull H I will send mail about URI schemes.
ggm: Scott its moderated list.
brabson left the room.
resnick left the room (Disconnected).
ggm: Scott no more to talk about? Blue sheets
ggm: done.


Open Pluggable Edge Service (OPES)
Multihoming and Applications