[lemonade] Draft Minutes, Day 1 (THANKS EDWIN!!!)

Lemonade  - Day 1

Edwin is scribing, Tony is Jabbering

Jabber Logs: http://www.xmpp.org/ietf-logs/lemonade@xmpp.ietf.org/

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