Typically, an interoperability survey is required to go to draft.  
Considering that you may wish to reverse the order a bit.

Eliot

On 2/23/10 10:36 PM, Murray S. Kucherawy wrote:
> OK, dates:
>
>> -----Original Message-----
>> From: [email protected] [mailto:ietf-dkim-
>> [email protected]] On Behalf Of Barry Leiba
>> Sent: Friday, February 19, 2010 11:32 AM
>> To: IETF DKIM WG
>> Subject: [ietf-dkim] Proposed new charter
>>
>> [...]
>>    +++ New Work +++
>>    The working group is now ready to switch its focus to refining and
>>    advancing the DKIM protocols.  The current deliverables for the
>>    DKIM working group are these:
>>
>>    1. Advance the base DKIM protocol (RFC 4871) to Draft Standard.
>>       This is the first priority for the working group.
> Unfortunately I don't have any background doing this kind of work, so I'm 
> forced to guess.  But what about the July IETF as a "done-by" date?  Is that 
> a crazy idea?
>
>>    2. Collect data on the deployment, interoperability, and
>>       effectiveness of the base DKIM protocol, with consideration
>>       toward updating the working group's informational documents.
> July IETF.
>
>>    3. Collect data on the deployment, interoperability, and
>>       effectiveness of the Author Domain Signing Practices protocol
>>       (RFC 5617), and determine if/when it's ready to advance on the
>>       standards track. Update it at Proposed Standard, advance it to
>>       Draft Standard, deprecate it, or determine another disposition,
>>       as appropriate.
> November IETF.
>
>>    4. Taking into account the data collected in (2) and (3), update
>>       the overview and deployment/operations documents.  These are
>>       considered living documents, and should be updated periodically,
>>       as we have more real-world experience.
> February 2011 IETF.
>
>>    5. Consider issues related to mailing lists, beyond what is
>>       already documented.  This includes considerations for mailing
>>       list software that supports or intends to support DKIM, as well
>>       as considerations for DKIM/ADSP deployment in the presence of
>>       mailing lists that do not have such support.  Include
>>       recommendations in the informational documents, or produce a
>>       new informational document about mailing-list considerations.
> I think this can be done in parallel, so November IETF.
>
>
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Reply via email to