Subject: [lemonade] What is Profile-bis?

From: Eric Burger <[email-masked]>
Date: Fri, 15 Feb 2008 12:33:49 -0500

This message is being sent in my capacity as Chair by request of the
lemonade Work Group leadership.

There have been a few postings about what should or should not be in
Profile-bis.  It is worthwhile to revisit both our charter in general and
what Profile-bis is in particular.

Our charter is to deliver protocol extensions to the Internet messaging
infrastructure, specifically IMAP and SUBMIT, to enable or enhance messaging
in ANY environment that has the characteristics of low or intermittent
network connectivity, low power clients, or clients of lesser capability.
This is the lemonade environment.  In practical terms, this means we will
develop a set of standards-track RFC's, BCP's, and Informational documents
describing extensions to existing protocols, possible deployment
architectures, and issues to be aware of with respect to or that enhance the
lemonade environment experience.

In an orthogonal effort, the IETF has been formally approached by the OMA to
satisfy a number of requirements that just happen to have constraints of low
or intermittent network connectivity, low power clients, and clients of
lesser capability.  This is convenient for us, as this means we can use the
RFC's, BCP's, and Informational documents to satisfy the OMA's requirements.

Very early on in the process, there was consensus in the work group that it
would be valuable to produce a document, targeted towards the OMA, that in
detail describes in one place how the suite of existing standards and new
standards that we develop in lemonade achieve the OMA requirements.  This
document is the lemonade Profile and its successor, Profile-bis.

With this in mind, we would like to take this opportunity to remind the work
group what Profile-bis is, and what it is not.

First, what Profile-bis is not.  Profile-bis is not a protocol profile.
From a pure, IETF protocol perspective, there is no such thing as a
"lemonade protocol."  What this means in practice is all of the respective
protocol operation and negotiation occurs in the context of the individual
standards, NOT as a whole-cloth lemonade protocol.

Other groups may chose to BRAND clients and servers that happen to implement
all of the components of the Profile as "lemonade clients" or "lemonade
servers."  However, that is a marketing, industry consortia, or testing lab
activity.  For example, the OMA may chose to grant OMA interoperability
certification of all of the respective features important to THEIR
embodiment of the lemonade environment.

Now, what Profile-bis is.  Profile-bis collects all of the protocol bits the
OMA environment requires and describes how these protocol bits fit together
in the OMA environment.  Please note well the "OMA environment" is a strict
subset of the "lemonade environment."  The OMA environment is specifically
the environment described in the Mobile Email Requirements Document at
http://www.openmobilealliance.org/release_program/docs/RD/OMA-RD-MobileEmail
-V1_0_20051018-C.pdf

So, what does this mean in practice?  This means that there will be
documents the lemonade work group produces that will be valuable, important,
and not in Profile-bis.

I have a personal mea culpa here: I suggested future delivery could go into
Profile-bis.  However, future delivery is not an OMA MEM requirement.  As
such, it does not belong in Profile-bis.

This does raise two issues we would like to open for discussion.  The first
is there clearly is some ambiguity as to what the Profile-bis document is.
Even your now humbled chair could not get it right.  I would suggest we
change the title of the document to

   The Lemonade Profile for the Open Mobile Alliance (OMA)
              Mobile E-Mail (MEM) Enabler

The second is to solicit the level of interest in producing a grand,
all-inclusive lemonade profile that encompasses all of the Lemonade Profile
for the OMA MEM (Profile-bis) as well as the other useful features we have
developed for other lemonade environments besides OMA MEM, such as future
delivery and the streaming of multimedia content.

Please respond to these two questions in the separate threads with the
Subjects "New Title for Profile-bis" and "Solicitation for Another Profile
Document" respectively.  If you wish to discuss the scope of Profile-bis,
please do that on this thread.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
_______________________________________________
lemonade mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: <[email-masked]>
Date: Mon, 18 Feb 2008 13:51:03 +0200

Hi Eric,
I have some comments/questions below.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Eric Burger
>Sent: 15 February, 2008 19:34
>To: [email-masked]
>Subject: [lemonade] What is Profile-bis?
>
>I have a personal mea culpa here: I suggested future delivery 
>could go into Profile-bis.  However, future delivery is not an 
>OMA MEM requirement.  As such, it does not belong in Profile-bis.

I thought future delivery is not going into the Profile-bis; however, it will be "recommended".
If I interpret it correctly, even a recommendation (of something that is not an OMA MEM requirement) cannot be part of Profile-bis.
Is this interpretation valid?

Thank You.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 18 Feb 2008 13:00:34 +0000

Hi Zoltan,

>Is this interpretation valid?
We had an agreement in the WG early on to make all extensions in 
Lemonade Profile Bis mandatory for servers to support.
I think we will get ourselves into all sort of troubles during the 
deployment phase if we try to change this agreement.

But note, this is just an agreement and if there is a really good reason 
for changing it for some extensions, such change can be considered.

---

From: <[email-masked]>
Date: Mon, 18 Feb 2008 15:06:13 +0200

Hi Alexey,
yes, I am aware of the agreement. In light of that, please let me
re-phrase my question: does a recommendation make a draft part of
Profile-bis?

>From: ext Alexey Melnikov [mailto:[email-masked]] 
>Sent: 18 February, 2008 15:01
>To: Ordogh Zoltan (Nokia-D-MSW/Tampere)
>Cc: [email-masked]; [email-masked]
>Subject: Re: [lemonade] What is Profile-bis?

>>>I have a personal mea culpa here: I suggested future 
>delivery could go 
>>>into Profile-bis.  However, future delivery is not an OMA MEM 
>>>requirement.  As such, it does not belong in Profile-bis.
>>>    
>>>
>>If I interpret it correctly, even a recommendation (of 
>something that is not an OMA MEM requirement) cannot be part 
>of Profile-bis.
>We had an agreement in the WG early on to make all extensions 
>in Lemonade Profile Bis mandatory for servers to support.
>I think we will get ourselves into all sort of troubles during 
>the deployment phase if we try to change this agreement.
>
>But note, this is just an agreement and if there is a really 
>good reason for changing it for some extensions, such change 
>can be considered.
>
>

---

From: <[email-masked]>
Date: Mon, 18 Feb 2008 12:26:59 -0600

From an OMA perpsective, there is enough in profile bis as is. So yes,
lets stick to the orginal agreement that drafts in profile bis will be
manadatory on the server.

If there are Lemonade recommendations, OMA can reference the separate
draft as a recommendation, this is not a problem.   We can reference
other IETF drafts besides profile bis.

BR,
Dorothy

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, February 18, 2008 5:06 AM
> To: [email-masked]
> Cc: [email-masked]
> yes, I am aware of the agreement. In light of that, please 
> let me re-phrase my question: does a recommendation make a 
> draft part of Profile-bis?
> 
> >something that is not an OMA MEM requirement) cannot be part of 
> >Profile-bis.
> >But note, this is just an agreement and if there is a really good 
> >reason for changing it for some extensions, such change can be 
> >considered.
> >
> >

---

From: Eric Burger <[email-masked]>
Date: Wed, 20 Feb 2008 16:19:18 -0800

Good thing we work by consensus and not fiat.

There is strong consensus not to change the title of Profile-bis.  Moreover,
people seem happy that we will keep our integrity to Profile-bis' purpose by
making it clear in the Abstract and Introduction that Profile-bis' goal is
to satisfy the OMA MEM requirements.

Operationally, this means the primary factor for in/out decisions are the
OMA MEM requirements.  It also means we dodge the "Is this the OMA MEM
Enabler" question entirely, as the Lemonade Profile is a proper subset of
the OMA MEM requirements.  For example, the lock & wipe functionality is
clearly out of scope for the IETF, yet it is a clear requirement for the MEM
Enabler.

We also know from painful interoperability experience there will be little
to no conditional requirements (SHOULD, MAY, etc.).

As to a comprehensive Lemonade document, some felt it was important to do
someday, others felt it could wait, and others think it would make a good
O'Reilly book.  Given that, we will not be adding a new milestone at this
time.

Thanks for your input and near universal consensus.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 20 Feb 2008 22:17:26 +0000

>re-phrase my question: does a recommendation make a draft part of
Based on a the current agreement, a recommendation (i.e. RECOMMENDED == 
SHOULD using RFC 2119 keywords) on an extension can't be added to 
Profile Bis.

>>>>I have a personal mea culpa here: I suggested future delivery could go 
>>>>        
>>>>

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Feb 2008 10:33:12 -0800

At 4:19 PM -0800 2/20/08, Eric Burger wrote:

>  There is strong consensus not to change the title of Profile-bis.

Yes.

>  Moreover,

This is a goal, but should not be the only goal.

>  OMA MEM requirements.

I'm not sure that this should be the primary factor.  We do want to 
meet OMA requirements, but we also want to produce a good IETF 
document.

>  It also means we dodge the "Is this the OMA MEM

Yes.

>  to no conditional requirements (SHOULD, MAY, etc.).

What we've been doing so far is making server behavior mandatory and 
client behavior optional.  That way clients can interoperate with any 
lemonade-bis-compliant server.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
It wasn't as easy to get programs right as we had thought.
                                           --Wilkes, 1949
_______________________________________________
lemonade mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade