As indicated today, = we will be sending a liaison response to the OMA on Friday.

There will be two = pieces:
1. the = cover letter I have pasted below
2. the = preliminary analysis as posted earlier this week and modified as = presented today by Greg

To: OMA MWG MEM Sub Working = Group
From: IETF LEMONADE Working = Group
Date: August 6, 2005
Subject: Regarding the OMA = Mobile Email Requirements Document (RD)
Purpose: For Action
Deadline: August 31, = 2005

The LEMONADE working group (WG) = would like to thank the OMA Mobile Email Sub Working Group for sharing = the current version of the Mobile Email Requirements document. = This has been made available to the LEMONADE participants on our = supplemental website.

We have attached a preliminary = response to each of the Mobile Email requirements that are in the = unapproved version of the RD you sent to us. We indicate the = likely IETF mechanism (if applicable) to solve each of the = requirements. Note that this is our initial reaction and we would = prefer a detailed discussion to ensure comprehension.

We would like to draw your = attention to the fact that LEMONADE is currently wrapping up the first = phase of its work. This means that final IETF review is currently = underway and that publication of LEMONADE Phase 1 as RFCs is likely = before year end.

The IETF LEMONADE WG is working = on the mobile email topic and we believe our work to enhance Internet = Mail is relevant to your requirements. However, our charter is = specific on what aspects we are working on. The WG is determining = if it can cover all of the relevant OMA requirements that affect = Internet protocols under its current charter – or if the charter = needs to be updated – or if the another new or existing WG needs = to be involved. In either case, any Internet mail enhancements = required will be covered under what we are terming LEMONADE Phase = 2.

LEMONADE Phase 2 is currently in = the goals/requirements stage. This would probably last until our = next meeting. The timeline would likely result in protocol = proposals being accepted as WG documents later this year with review and = conclusion later in 2006.

Lemonade - Day = 1

Edwin is scribing, Tony is Jabbering

Jabber Logs: http://www= .xmpp.org/ietf-logs/lemonade@xmpp.ietf.org/<= /p>

Agenda = Bashing

The chairs noted one unlisted item on the agenda: a discussion at the end of = day 2 of where we should go next, specifically whether there will be any = additional interim meetings.

No other comments to the agenda

Status of Documents – Chairs

Goals doc is (still) in the RFC Editor Queue

· 30 of the references are = reported dangling; need to verify that text hasn’t been lost

Server to Server notification requirements

· Updates needed from IESG = comments; author has reappeared and confirmed that he will make necessary updates = to the document

MMS Mapping

· IESG approved, appealed, = approval rescinded, new draft needed (details to come later today)

Forward without download trio

· Currently in IETF last = call, pending IESG review

· Q from Ted: were we = planning to do anything with Randy’s comments (on BURL and CATENATE)? = Incorporate as an RFC editor note or were there other last call comments? Chairs = will put together a summary and verify that there weren’t any other last = call comments. Meanwhile, Randy summarized his comments on the trio = docs:

o = BURL: most were minor; Chris offered to do a quick rev to incorporate comments = if it won’t cause hiccups in the process

o = Catenate: minor typos, but pointed out that the draft contains no normative = language. Randy asked to verify that’s the direction we want to go. = Ted asked whether anyone found the lack of normative language a concern for = implementation? No one took issue with the lack of normative language.

o = URLAUTH: Randy had some additional comments that haven’t been sent = yet.

· Edits to be incorporated = and sent to Ted for IESG review

Future Delivery

· WGLC closed; was going to = create a new draft before IETF last call

· Sent to editor past the = deadline for this meeting.

· Will request IETF last call = on the new draft

Reconnect

· Changes were minor nits: = clarified security session to reflect Feb. Minneapolis changes; IESG comments to = make changes to the IPR header and other minor normative references; other = minor changes based on comments

· There was a discussion, = initiated by Pete, about whether we wanted to tackle the reconnect issue in = LEMONADE as an application-level issue or look at it at the transport = layer:

o = Pete suggested that perhaps we could defer to shim6, but others observed that = shim6 did not have any IPv4 in its charter. Others were uncomfortable = with having a critical path dependency on shim6.

o = Other technologies that are looking at this: HIP and others

o = Keith suggested that a nearer term solution might be TLS.

o = Ted pointed out that there are at least 10 active efforts looking at this = problem at the internet architecture layer, and Phillip added that there are two = in LEMONADE as well.

o = The IPv6 co-chair mentioned he would like to get input or feedback from here = into the applicability document to help motivate shim6 work.

o = Dave suggested formulating the question into what this application layer = needs from a transport layer below.

o = Glenn: The solution for IMAP is within our charter and is something we want to = do. In the profile document, should specify that there are multiple options. = There seems no reason to pull this from our set.

· Some elements are = absolutely needed: e.g., delta set notification; can pull out the connect/reconnect = and put that in the lower layers if needed.

· Should we make it = experimental? Some dissent; comparison to VPIM from some years back.

o = Eric: We had this conversation before. Reconnect doesn’t harm = anything; has some useful characteristics, would recommend going = forward:

· WG agrees to go forward = with WGLC

Intermediaries and S2C Notification Requirements

o = Discussion deferred to phase 2 (tomorrow)

MMS Mapping – Randy = Gellens

Status

· -04 approved by IESG but = appealed

· Issues discussed on list = ~6/10-7/5

· Looks like consensus on = x-headers ~6/28

· IESG resolution allows = group to revise and go through an additional cycle of WGL

Issues

· Very little group = discussion after –02

· “SHOULD” retain X-MMS-Message-ID

o = Concern that that language standardized X-headers; delete any text of retaining = X-MMS headers

· Maps X-MMS-Priority to both X-Priority and Importance

o = Concern that this was standardizing X-priority; result: not map to X-Piroirty = but mention it in an informative section

· Suggests using comment = instead of group syntax to indicate sender address hiding

o = Invalid for 2821

· ESMTP vs. = SMTP

o = Talks about ESMTP and SMTP mostly merged; appeal felt that this was a = violation of ESMTP – all new mentions should be of ESMTP; most of the SMTP text = can be removed

· Text on address hiding in = 2.1.3.2

o = MMS systems employ this, so if a gateway receives MMS message intended for = the Internet.

o = Some discussion about whether this text should be there.

· Text on media conversion in content-type in 2.1.3.2

o = If you receive a message from MMS not in widespread use on the Internet, potentially downconvert it

o = Any advice about content conversion should be left silent

· Language on gateways and = relay servers

o = Can probably just be edited

· Statement about 2821 for = null return-path to prevent mail loops

o = 2821 does not actually require it; may want to clarify the = wording

· Resent-Count = header

o = Not standardized anywhere: suggestion to delete mention of resent = count

· Text on quoting and Resent = and Received headers in 2.1.3.2.2

o = Suggestion from appeal was to delete this section in its entirety

· Lack of specific response = code in “sensitivity” text

o = Need to be more specific about what response code to send back

· Security = Considerations

o = Had a bunch of text that the appeal objected to

o = Much of the text could probably be deleted

· MMS references not = normative

o = This introduces some other considerations for the requirements for normative references

· Bcc example in section 3 is incorrect

· Handwaving on creating = Message-ID

o = Text could potentially be made more rigorous

· Needs text on unqualified addresses

o = Proposal: unqualified addresses should be rejected

· Text on anonymous = remailiers and signed mail in section 3 is “silly”

o = Could probably be deleted

· Incorrect or incomplete = text in Section 3 (SMTP auth, S/MIME, PGP)

o = Text will need to be looked at

· Semantic mismatches between = the Diposition-Notififcation-To header in [MDN] and X-MMS-Read-Reply = header

Resolution

· X-headers issues resolved = on list

· Do need some discussion = on

o = Sender address hiding

· Normally, within Internet protocols, the message will be sent through the system and rely on the = UA to remove the address; obviously doesn’t work for Internet = mail

· Can include text on why = sender address hiding is a bad idea

· Not much comment from the = room.

· Usefor (Usenet format) WG = was requesting a similar feature; there was some desire for = this

· Glenn: VPIM: Unknown was = created for this purpose (unknown@domain); = but domain was known

· Randy could clean up text = to indicate that we are not supporting sender address hiding but include = some more text that does the semantic mapping

o = MDN vs. MMS read-reply

· Discussion taken to the = list

o = Require null return path for automatically-generated messages

· Is there a reference to RFC = 3834 in the draft?

· Suggestion to propose = specific text to the list and encourage discussion

· Other text changes needed = (-05) and will resubmit for last call

Lemonade = Profile

Changes Since –02

· Changes are mostly = editorial

· More substantial = changes:

o = Updated examples to match the current trio docs

o = Some clarifications on using TLS, but this section still needs more = work

o = Qualified normative statement on future delivery (“SHOULD” downgraded = to “MAY”) but this is still an open issue

Open Issues

· Randy: is quick-reconnect = part of v1?

o = A: Previous discussion leads me to believe it is, so current text and = examples need to be expanded

· Randy: is future delivery = part of v1? Not a good idea to have too many optional features; need to = determine whether it is mandatory or optional

o = Comment in favor of keeping it mandatory

o = Randy: If they are part of the profile, then they need to be mandatory so that = the server can say that it supports it and write a simple = client

· The group entertained a = lengthy discussion about what it meant to be “Lemonade v1 = compliant”

o = Eric: there is still no bulk capability negotiation; each extension is still individually specified, so is compliance really a marketing = issue?

o = Stephane: Nothing prevents us in the future from have a bulk set of = properties.

o = Dwight Smith: How is the profile handled on a process perspective? Is = there a compliance statement? A: It’s a squishy concept; there is no = bulk negotiation for lemonade compliance. Profile document summarizes a = set of standards that is used for a particular application. Intent is = that it’s a bundle that allows implementers to look at a single place for implementation. Pete: There’s nothing to stop OMA from = pointing to this document (for example) and indicate that this is their compliance = document. Profile document also has a bunch of applicability statements that are = useful.

o = There was a question if the profile document was intended to be = normative? If yes, then there are ambiguities.

· Profile document is useful = to specify a bundle of extensions

· And to inform clients as to = how to use the various extensions to accomplish a specific task

o = Stephane: At the end of the day, an implementer needs to implement mobile = email. OMA Mobile email doesn’t require future delivery; including future = delivery within Lemonade means that an OMA client must implement it in order to = be Lemonade compliant.

o = Philosophy question: should a profile be the smallest possible set of aggregation = to implement a particular set of functionality.

o = Randy: Reason to have a normative profile is for implementers that create = clients on constrained platforms to avoid having to create code paths to deal with = servers that implement parts of it.

o = Chair position: profile v1 as specified here is in charter and we’re = doing it. The OMA liaison will help direct phase 2.

o = No clear consensus: take this to the list

· Randy: TLS Section needs = more work

· Draft editing/catenation = examples are omitted

o = Randy: if they’re in catenate, then they don’t need to be here; = agreed

· Need to select which = extensions are mandatory and which are optional:

Mandatory/Optional IMAP Extensions

· STARTTLS – MUST (RFC = 3501)

· CATENATE – MUST (Fwd = w/o download)

· URLAUTH – MUST (Fwd = w/o/ download)

· UIDPLUS – Suggest = MUST (makes things easier)

o = Has to be a must; without UIDPLUS, you don’t get the UID back to = create a CATENATE URL

· POSTADDRESS

· RECONNECT – yes, see = above

Mandatory/Optional SMTP Extensions

· AUTH – MUST required = by Submit

· BURL – MUST = (Fwd)

· FUTUREDELIVERY – = taken to list

· PIPELINING – = suggestion: MUST (SHOULD)

· STARTLS

· 8BITMIME – MUST = (required by BURL)

· CHUNKING

· BINARYMIME

· DSN

· SIZE

· ENHANCEDSTATUSCODES

Discussion:

· We should do those things = as MUST that a mobile environment would think of us looney for not = having

· In order to simplify clientimplementation, we shouldn’t have any SHOULDs; everything = should either be MUST or MAY

· Some discussion on whether = you need 8-bit downconversion if 8BITMIME is a MUST

· STARTTLS

o = Chris expressed a concern over whether STARTTLS should be a MAY from a = security perspective

· Concern was that STARTTLS = was not implemented in mobile handsets

o = John suggested STARTTLS and CRAM MD5 are orthogonal; STARTTLS can be a MUST, = but we should also have CRAM MD5

· Discussion about whether = plain vs. MD5 passwords on the server are more secure. Assertion is that server = passwords could be made more secure by using plain and implementing additional preprocessing on the server.

· Keith: argued that CRAM MD5 = is likely to be deprecated shortly; it seems awkward for us to suggest the = use of CRAM MD5 at about the time that they’re likely to be = deprecated.

o = Randy: OMA requirement is mutual auth; plain doesn’t satisfy this = requirement. TLS with expired or self-signed certs is also a reality.

o = Proposal from Chris: Plain w/ STARTTLS is mandatory to implement, not necessarily mandatory to use.

o = If we want STARTTLS due to security, we need to also specify a minimum = cipher suite.

o = Chris: We can’t mandate that implementations be secure, but we can say = that unless a set of recommended system is

o = Eric: Concern is that people don’t tend to pick particularly good = passwords. C/R schemes: server needs to store the same set of credentials that the = client generates to validate the password.

o = Consensus: STARTLS is a MUST; FUTUREDELIVERY will be taken back to the list; = everything else is a MUST

Next steps:

· Is there sufficient work to = submit a new draft, or does the FUTUREDELIVERY work need to be = done?

· Needs from the mailing = list: FUTUREDELIVERY and a syntax for RECONNECT

· The chairs took a hum to = see if Future delivery should be part of Profile v1.

o = There was clear consensus in the room that future delivery should not be part = of Profile v1.

· Those with strong = objections should note on the list within a week

OMA = Collaboration

· RFC 3975 describes the = framework of collaboration with IETF

· Desire for most work to = happen at the WG level, but where necessary, the liaison ensures specific = processes for interaction.

· Working closely with Dean = Willis

· Once the liaison is = established, the intent is to synchronize requirements which are, in general defined = in OMA, with protocol specifications which will be defined in = IETF.

· IETF members have access to OMA’s normative dependencies for 3 enablers:

o = PTT (Push to Talk)

o = Presence

o = XDN

o = Some additional normative references for IM/SIMPLE

· Once requirements are = relatively stable, OMA looks to IETF, 3GPP, and 3GPP2 for common work. If = something is going on within the IETF, OMA will not replicate that work but will = contribute to the discussion in that group.

· Every two months conference = calls between OMA and chairs from the appropriate group; identify issues and = drafts which are not stable.

o = Currently, only 2 drafts identified as not stable that are necessary for the work = to proceed.

· Q: Right now there are no = lemonade dependencies; do we expect that will change? A (Stephane): Work = within OMA to date has been requirements; architecture work has started, so we would = expect that additional dependencies on LEMONADE will come.

OMA Mobile Email Liaison

Liaison Request

· Considers the OMA Mobile = e-mail requirements as input from the mobile community in terms of requirements = for mobile e-mail features that may affect the LEMONADE = Activities

· Provides feedback on the = possible relevance of LEMONADE work

· Provides its view on = preferred potential collaboration

· Encourages participants who = work for OMA member companies to accept the invitation to attend the OMA = Mobile E-mail SWG interim meeting

o = Suggestion about whether we should have joint meetings in the = future.

o = Stephane pointed out that OMA can have workshops, but not have decision-making = meetings with non-OMA members.

o = Suggestion that the LEMONADE response include a list of documents that = apply

IETF Response

· Lemonade chairs will = present at OMA Mobile Email interim 8-9 Aug. in Paris. Topics will include:

o = What is LEMONADE

o = What is Internet Email

o = Comments on requirements

· Drafts on these are on the supplemental site

· Comments welcome this = week

End of Lemonade Day 1