Subject: Lisa's Apps Area Activity for August 2007

From: Lisa Dusseault <[email-masked]>
Date: Tue, 4 Sep 2007 14:05:02 -0700

Document Status and Progress

Active Documents: my action
  - draft-adolf-dvb-urn (Informational): need to do AD evaluation
  - draft-creed-ogc-urn (Informational): need to do AD evaluation
  - draft-mealling-epc-urn (Informational): discussing design space  
with author
  - draft-wilde-sms-uri (Proposed Standard): discussing extended  
features on Apps Discuss
- draft-ietf-sieve-3028bis: IESG Evaluation,  work with Cullen and  
doc shepherd on multiple redirect issues
  - draft-saintandre-rfc4622bis: Finished IETF Last Call; I need to  
read reviews and do writeup for IESG Evaluation phase.
  - draft-ietf-imapext-sort:  Confirming that this is done now that  
unicasemap is done.

Stalled or waiting on other
  - draft-snell-atompub-bidi (Proposed Standard): Sent to ITU for  
review of bidi character handling.
  - draft-saintandre-jabberid: In IETF Last Call
  - draft-ietf-sieve-body: Finished IETF Last Call, waiting for  
revision (Philip).
  - draft-crocker-rfc4234bis: Finished IESG Evaluation, waiting for  
author to resolve LWSP issue raised in IETF Last Call and IESG  
Evaluation (Dave or Paul)
  - draft-snell-atompub-feature: Dissent on mailing list about  
required features indicates that this core building block piece for  
AtomPub probably shouldn't be done as an Individual document.  This  
will probably be put in stasis until an AtomPub WG gets formed to  
progress it, or some similar action.
- draft-hartman-webauth-phishing: New critical reviews received post- 
IETF-Last-Call.  Author will revise and discuss on ietf-http-auth  
mailing list.
  - draft-montemurro-gsma-imei-urn: IESG Evaluation phase, waiting  
for author to select a way to deal with Cullen's DISCUSS on whether  
to register just two URNs or an allocatable delegated namespace of  
arbitrarily many URNs.
  - draft-goodwin-iso-urn (Informational): AUTH48 changes were too  
substantial.  Waiting for authors to confirm that next action is to  
rerun IETF Last Call.

Finished processing - RFC queue and new RFCs
- draft-crispin-collation-unicasemap: Completed IESG Evaluation,  
pushing to RFC Ed queue
  - draft-ietf-lemonade-rfc2192bis: Completed IESG Eval and pushed to  
RFC Ed queue.
  - RFC 5013:  The Dublin Core Metadata Element Set
  - RFC 5034:  The Post Office Protocol (POP3) Simple Authentication  
and Security Layer (SASL) Authentication Mechanism
  - RFC 4954: SMTP Service Extension for Authentication
  - RFC 4946: Atom License Extension

  ... 12 sponsored or shepherded documents in RFC queue including  
above two just added.

WG quick status
WIDEX: Closed.
USEFOR: quiet during August
SIEVE: processing several active documents
IMAPEXT: Quiescent, waiting on busy authors.
ATOMPUB: Basically finished!
CALSIFY: Finishing RFC2445bis and doing work on iTIP

---

From: Dave Crocker <[email-masked]>
Date: Tue, 04 Sep 2007 14:45:04 -0700

> Evaluation (Dave or Paul)

The document authors have a number of problems with this Discuss from Lisa and 
efforts to clarify things privately have not been productive.

Since this is being distributed publicly, I am obligated to comment on it:

Simply put, there is not "LWSP issue".  The ABNF document has been in use a 
very long time and is formally accurate in in specification.  Over its 10+ 
year history, there have been a few examples of misreading the ABNF 
specification.  If that qualifies as a basis for mandating change, then we 
need to review quite a few other specifications.

In any event, there is a Discuss from Lisa that has stalled progress of the 
ABNF document, but the Discuss causes its own problems:

One is that we do not perceive any community consensus that any change -- 
nevermind no normative change -- is required for the document. At most, there 
might be some community interest in having commentary added, but that leads to 
the next problem.

We do not have any idea what will resolve Lisa's Discuss.  Lisa has provided 
no criteria for its closure, other than suggesting that we talk with one 
individual.  We are not aware the mere act of being vocal about an issue 
empowers a single community member to control resolution of a Discuss.  In 
effect, that would seem to be a delegation of the Discuss. Is that allowed?

If Lisa has requirements on this topic, she needs to state what they are in 
terms of her own understandings and requirements, not in terms of the 
unspecified needs of another.  We should remember that this is an extremely 
well-vetted document, both in long history and recent review.

Since the document's authors do not believe that the current process issues 
will alter the use of ABNF, we do not have much incentive to spend energy on 
the issue.  (A sour grapes muttering in response might claim that my writing 
this note -- and it is perhaps the third of its type I've send on the topic -- 
is more work than resolving the topic, but I'll note that that cannot be 
known, since there is now way of knowing what will resolve it.)

Lisa has stated that her Discuss really is on behalf of an IESG consensus that 
some text needs to be added.  Perhaps I missed the IESG minutes about this 
consensus?  It would be useful to get a citation to it.

In any event, if the IESG has consensus about the need to added commentary to 
an RFC before it is published, then this is an IESG requirement, not an IESG 
assessment of a community consensus.  Further there is a well-established and 
frequently-used mechanism for it.  IESG Notes are not exactly... noteworthy.

And for reference, the document authors have repeatedly stated their friendly 
willingness to add such text.  Or text that is produced by a community 
consensus process.  But since we do not, ourselves, understand what will 
satisfy Lisa in this matter, we do not feel qualified to lead the effort to 
resolve it.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net