Minutes from Apps area meeting

1.  LDAP Standardization status

Revised base specs are completed.  Next steps include interoperability testing/reports and moving to Draft Standard. See slides for details.

2.  Review of IDNA

Need to update to new Unicode version in order to avoid a lot of issues with Unicode canonicalization.  Also planning new definition of StringPrep profile.

See http://stupid.domain.name/idnabis/draft-faltstrom-idnabis-tables-00.htm
DL: idna-update@alvestrand.no

Some discussion about whether domain name registrars should be worried about new validity rules -- will the new rules make existing names invalid?  Only if they're already allowing some pretty weird names. 

Some discussion of whether to change the IDNA prefix -- current plan is to keep it the same as cost of change would be large and take much time.

3.  EAI status

Currently working on an experimental set of changes to allow UTF-8 in email addresses and headers.  This involves changes to SMTP, POP3, IMAP, mailing list handling.  One spec defines how to gateway these addresses to existing SMTP systems, via address downgrade to an alternate address provided by sender.  

The framework document is nearly finished and WG drafts exist for the other topics.  Some early implementation work has been done and no landmines found so far.

Some controversial issues:
	 - alt-address vs. encoding the i18n address
	- encapsulation vs. conversion at gateway downgrade -- currently going with conversion
	- exact format for alt-address.

4.  Current email standardization

IMAPEXT and LEMONADE currently working on email standards. IMAPEXT has finished ACLs, UIDPLUS, CONDSTORE and nearly finished sorting, threads, annotations and i18n.  LEMONADE is doing enhancements for clients with long or slow links, such as
	- forward without download
	- pushing notifications
	- content conversion

One open problem: IIMAP is MIME aware, but can't do S/MIME processing as it doesn't have the end-to-end keys.  Thus IMAP servers can't verify signatures or decrypt part of a message to walk into the nested MIME structure.  This limitation means that features like "forward-without-download" can't work when S/MIME is used.

5. IANA, port assignments and SRV records

Current procedures for registering port numbers are crufty.  The concept of a "well known port" is not a useful concept any more.  Many current registry entries are out-of-date.  One possible clean-up goal is to have port usage documented in terms of what's running on that port, only so that broadly deployed protocols can avoid conflicts.

Where appropriate, applications might use SRV records (RFC2782) instead of new port numbers. These are similar to MX records but not tied to SMTP.  Using DNS and SRV records allows multiple servers and prioritization among them.

On the down side, using SRV introduces a DNS dependency (might be new client code and requires service administrators to coordinate with DNS content) and could delay service establishment.  

Some discussion on whether firewalls might pose problems for using SRV records; difference of opinion (Eliot Lear "not really" and Thomas Narten "that underestimates the difficulties").

6.  TV URIs

draft-keesmaat-tvreg-00 proposed to identify TV broadcasts in URIs, currently constructed as HTTP URls.  Some possible use cases: a presence user could indicate that their current activity is "watching CNN"; schedules could use these standard identifiers.

Discussion of whether these different use cases should even involve the same solution.  The generation of URI values is different in each case (human vs. programmatic).  

Requirements: 
	- the identifier-to-broadcast mapping must be unique. 
	- broadcast-to-identifier mapping SHOULD be unique (at least small number)
	- IDs should cover all forms of TV broadcast, not just airwaves and cable.
	- Usable in IM, calendaring, etc
	- easy-to-use by humans (contrast to the existing VCR format???)

Issues:
	- Discussion of whether the first and last requirements conflict.  
	- Discussion of whether "CNN in hong kong" is different from "CNN in USA".  Perhaps references to a broadcast like "CNN" is too generic.  Should there be simplistic vs. elaborated references?  
	- Are the HTTP URLs that identify TV broadcasts required to be resolvable to HTTP pages? 
	- More generally, how does one know if a TV URI is valid? 

Requirements for a TV URI registry:
	- attaches identification information to URIs
	- can be searched or browsed by humans
	- should be implementable (filled in with commonly used values) even without full involvement of TV broadcast paries
	- Nice to have: mappable to local TV frequencies, channel numbers, IP addresses or other actual locator.

7. ORCHIDS

These look like IPv6 addresses, but they aren't, really.  They're designated for HIP experimentation.  Consists of a /28 allocation for use in shims.  Is this a good way to allow HIP experimentation to proceed?  IETF last call is ongoing so comments are solicited.