Subject: [xml2rfc] Various nits

From: Frank Ellermann <[email-masked]>
Date: Fri, 21 Oct 2011 06:37:59 +0200

Hi, so far I only tried "private" drafts for OpenSPF and
"normal" drafts intended to be RFCs.  Yesterday I wanted
an "unusual" draft *not* intended to be a RFC.

1st attempt: topblock="no"

That was a bad idea, the datatracker upload rejected it,
and when I didn't cancel the rejected submission, because
I thought uploading a fixed version will be good enough,
the datatracker upload logic entered a silly state.

Suggestion:  Add a Caveat to the topblock documentation.

2nd attempt: try to get the cancel URL by mail
That doesn't work for topblock="no", apparently there is
some logic depending on the first page even if the user
is logged in with a known e-mail address and password.

3rd attempt: try to bypass the stuck version 02 with a 03
That doesn't work, draft NN+1 cannot be submitted while
the "work in progress" draft NN cannot be cancelled.

4th attempt: Manual (e-mail) submission of a fixed 02
That does not work for ipr="none".  Suggestion:  For any
date after the original ipr="none" expired replace it on
the fly by the ipr="nofullshit" de jour.  Apparently this
is ipr=""noDerivativesTrust200902" at the moment.

5th attempt: (outcome not yet clear)
To suppress the non-applicable WG I tried &nbsp; as WG.
If submissionType="independent" did anything I'm not sure
what it did.  There is apparently no way to suppress the
intended status.  Maybe add category="none" with default
ipr="noDerivativesTrust200902" for drafts not intended to
be published as RFC.

Minor nit:  xml2rfc strict="yes" insists on the presence
of a section with Security Considerations.  This could be
disabled for the category="none" suggested above, because
an independent non-WG draft not intended to be a RFC does
not necessarily need Security Considerations.  Of course
I could simply use strict="no", but for various reasons I
prefer strict="yes" whenever possible.

-Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 21 Oct 2011 16:05:28 +0200

Hi Frank,

> Suggestion:  Add a Caveat to the topblock documentation.

Makes sense.  Without the first-page header neither
document author extraction or document date extraction
will succeed.

> is logged in with a known e-mail address and password.

Here I don't understand why you didn't just cancel using the
web interface?  This is the expected way to cancel, so if
it doesn't work I'd like to understand why, so it can be
fixed ...

I tried it myself:  Created a document with <?rfc topblock="no"?>,
uploaded it, got the meta-extraction errors, and cancelled
it, without any problems, I believe?

> the "work in progress" draft NN cannot be cancelled.

That is as designed.

> is ipr=""noDerivativesTrust200902" at the moment.

Replacing ipr='none' with something else may give a document
with different IPR restrictions than the document author
intended -- I don't think that's good.

Possibly the tool should produce no output for 'ipr="none"',
and suggest the valid possibilities.

> To suppress the non-applicable WG I tried &nbsp; as WG.

That still leaves "Network Working Group" at the top.
Maybe you could use <workgroup>None</workgroup>?

> ipr="noDerivativesTrust200902" for drafts not intended to

That could be a possibility, yes.

> prefer strict="yes" whenever possible.

Understood.  Makes sense.

Best regards,

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 22 Oct 2011 02:19:43 +0200

On 21 October 2011 16:05, Henrik Levkowetz wrote:

>> I didn't cancel the rejected submission, because
>> I thought uploading a fixed version will be good
>> enough
[...]
>> 2nd attempt: try to get the cancel URL by mail
[...]
> Here I don't understand why you didn't just cancel
> using the web interface?  This is the expected way
> to cancel, so if it doesn't work I'd like to
> understand why, so it can be fixed ...

See above, "cancel" did not sound good, and I tried
the "above all first upload a good draft" approach.
But that killed the "immediate cancel opportunity"
(I'm talking about two datatracker browser 'Tabs'.)

Of course the effect upset me because I hate it when
I'm excessively stupid.  OTOH, why cancel something
that is broken and not good enough for a submission?

Instead of a volatile "immediate cancel" opportunity
a simple "you lose" info (one of these xml2rfc jokes)
would be far simpler.  All xml2rfc online users know
the drill, upload, get "you lose", fix and try again,
repeat until ready.

Of course *now* I know how this is supposed to work,
and there is a good chance that I won't visit this
trap and pitfall again.  But I think this trap is not
required at all in the workflow:  A broken draft is a
broken draft, there should be no need to "cancel" it.

>> 3rd attempt: try to bypass the stuck version 02
[...]
> That is as designed.

ACK, the NN+1 design is clear, there can't be a NN+1
if NN never made it.  The design problem is that a
broken NN can block the fixed NN' if an uploader did
not immediately click "cancel".

>> Suggestion:  For any date after the original
>> ipr="none" expired replace it on the fly by the
>> ipr="nofullshit" de jour.  Apparently this

> Replacing ipr='none' with something else may give a
> document with different IPR restrictions than the
> document author intended -- I don't think that's
> good.

The documentation apparently says that the effect for
some ipr= values depends on the date in the draft...

If that's really so it's a cute feature, and it could
be used consistently for generic names such as "full"
or "none".  BTW, in the given case I'd be quite happy
if *somebody* violates this "no derivative" blurb and
writes an RFC.  All I wanted to have clear is that I
don't volunteer for this job.  This "not for RFC" use
case is slightly unclear; but maybe it is only me. ;-)

  [5th attempt]

> That still leaves "Network Working Group" at the

Oops, no, &nbsp; worked for me.

> Maybe you could use <workgroup>None</workgroup>?

Yes, I considered "Non-WG" or "Independent submission"
or closed WGs such as "HTML" or "Atom", but eventually
settled on &nbsp;.  FWIW, presumably it is irrelevant,
but after so many failures I wanted at least this bit
of personal "boilerplate avoidance" in the I-D...-02.

-Frank

---

From: Julian Reschke <[email-masked]>
Date: Sat, 22 Oct 2011 09:34:20 +0200

On 2011-10-22 02:19, Frank Ellermann wrote:
> ...
> ...

<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#boilerplate>

Yes, @ipr is confusing. Some values depend on the date, and that's good 
because if the actual IPR statement didn't change (as opposed to 
editorial changes), it's better not to bother people with changing their 
documents.

"full", as far as I can tell, never was a supported value.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 23 Oct 2011 15:53:34 +0200

Hi Frank,

> (I'm talking about two datatracker browser 'Tabs'.)

Hmm.  That doesn't sound right; it should always be
possible to cancel a submission.  Did you try to use
the browser 'back' button to go back to the upload
page you got after the first upload?  I see in the
database that there are two upload attempts, and they
have different IDs, so it should be possible (still!)
to go back to the original upload result page and do
a cancel.

> the drill, upload, get "you lose", fix and try again,

I think the reason that we didn't take that path is that
it removes the option to fix meta-information.  But it
should still be possible to improve on the current
situation, and maybe the idea of providing the option
to correcting the meta-information is sub-optimal.  We
will have to think about fixing that.

Could I ask you to enter an issue about this for the submit/
component in the issue tracker at
  http://tools.ietf.org/tools/ietfdb/ , please?

> Oops, no, &nbsp; worked for me.

Ah!  Ok, I should try that again, then.

> of personal "boilerplate avoidance" in the I-D...-02.

Understood.

Best regards,

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 25 Oct 2011 14:41:27 +0200

On 23 October 2011 15:53, Henrik Levkowetz wrote:

> That doesn't sound right; it should always be
> possible to cancel a submission.  Did you try
> to use the browser 'back' button to go back to
> the upload page you got after the first upload?

I *think* (could be wrong) that I tried obvious
ideas to get back to the cancel-page, but it did
not work.  But I forgot the details, maybe there
was a login between failure + new upload attempt.

I got the "send cancel URL" form, but that didn't
work without the notorious top page.  (In fact it
didn't tell me this, I can only guess that the
form ignores the login and needs the "top page".)

>> All xml2rfc online users know the drill, upload,
>> get "you lose", fix and try again, repeat until
>> ready.

> I think the reason that we didn't take that path
> is that it removes the option to fix meta-
> information.

Okay, my naive idea would be that a "good" version
NN should always be able to replace any "bad" NN;
for all values of "bad" = "too bad to be posted".

A kind of "implicit cancel", if that concept helps
with what you have now.  Anything requiring more
than one line of code or more than five minutes,
only because I managed to find a dark corner for
"missing top page", would be overkill:  I promise
that I won't try this again... :-)

> We will have to think about fixing that.

If it's a "we" divide "5 minutes" by thinking gurus.

> Could I ask you to enter an issue about this for
> the submit/component in the issue tracker at

Testing this now:
<http://trac.tools.ietf.org/tools/ietfdb/ticket/718>

Thanks,
 Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 25 Oct 2011 14:53:18 +0200

Hi Frank,

> was a login between failure + new upload attempt.

Ok.

> form ignores the login and needs the "top page".)

Uh.  I see.  It couldn't find a submitter email, so
didn't know where to send the link, probably.

> that I won't try this again... :-)

Ok.  I think it will take a bit of redesign, but I
also think it would be a better design.

> <http://trac.tools.ietf.org/tools/ietfdb/ticket/718>

Thanks for this!

Best regards,

	Henrik