Subject: [Tools-team] Minutes from the 13 April 2005 Telechat

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 13 Apr 2005 18:28:37 +0200

Hi,

Here are the minutes from today's meeting.  

---------------------------------------------------------

0. Present: Bill, Alex, Henrik

1. Agenda bashing

	Nothing

2. Comments on minutes from last teleconference.

	None

3. Action item review.

   * Stas: 	Continue working on the Notification Service
		Requirements.
	-

   * Alex:	Handle the last current comments on the submission draft
		and post to the list for polishing.

	All comments applied, spell-checking left, will then post to
	the list.

   * Alex:	Continue filling in missing parts of the ID info draft,
		provided no adverse comments on the direction of the
		recently posted version.

	No progress this week.

   * Henrik:	Help with the mapping of notification elements to Atom

	Started thinking, hope to complete this till next call

   * Henrik:	Help with language polishing of the submission draft

	Will be done once the draft comes to the list

   * Donald:	Continue work on the scheduling tool prototype; next
		step will be a form for data/constraints input to the
		scheduling

4. Any other business.

	Bill haven't heard more about the liaison tool - but the
	tool doesn't match the draft any more and has to be updated
	before it can be tested.

	Henrik will add pages for the iab and iesg drafts, equivalent
	to the WG pages.

	Some discussion of how to move toward getting xml2rfc to
	validate the input, but no firm path forward.  It seems
	that it's not possible to rely on any particular validator
	being present on any given Win/Linux/BSD/Mac platform, so
	a TCL validator would probably be best; but Marshall currently
	isn't interested in integrating a full validator into the
	tool.

5. Action items for next week.

   * Stas: 	Continue working on the Notification Service
		Requirements.

   * Alex:	Spell-check the submission draft and post to the list for
		polishing.

   * Alex:	Continue filling in missing parts of the ID info draft,
		provided no adverse comments on the direction of the
		recently posted version.

   * Henrik:	Help with the mapping of notification elements to Atom

   * Henrik:	Help with language polishing of the submission draft

   * Donald:	Continue work on the scheduling tool prototype; next
		step will be a form for data/constraints input to the
		scheduling

6. Next meeting:

  Teleconference Wednesday 20 April, 16:00 GMT (same local time as
  today).

---------------------------------------------------------
Connection details:

To join the call, dial +1-734-615-7474 and enter PIN 0151989.

One can also join the call by dialling:
 sip:[email-masked] 
on a SIP-enabled voice communications client. 

If the SIP client cannot dial URLs, you can have the conference
system call you if you have the sip URL for your phone.  Go to
 https://edial.internet2.edu/call/0151989
and type in the URL to your phone, and follow the directions.

_______________________________________________
Tools-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-team

---

From: "Alex Rousskov" <[email-masked]>
Date: Wed, 13 Apr 2005 12:08:14 -0600

> 		and post to the list for polishing.

Attached are TXT/XML/HTML versions of the ID Submission Toolset draft
in a gzipped tar archive. The Change log is quoted below.

I think this draft version addresses all comments received so far.
Please let me know if I missed anything and do the last round of
polishing, as agreed.

Thank you,

Alex.

------------ changes since draft-ietf-tools-draft-submission-07 ---------

       *  Clarified that the secretariat does not intend to correct
          drafts submitted for manual posting.  If the draft needs
          tweaking to match submitter's intent, then the draft should be
          corrected and re-submitted.

       *  Renamed "lawful submitter" to "expected submitter" to avoid an
          incorrect implication that some kind of new legal checks are
          involved.  Without an email interface and the Secretariat in
          the loop, the submitter must still be "expected" and
          authenticated to avoid script kiddies from overwriting posted
          IETF drafts with junk.

       *  Clarified that R68 and other multi-stage requirements with
          multi-stage features are to be interpreted by ignoring features
          that will be implemented at a later stage.  For example, "text
          or XML" means just "text" until XML support is added.

       *  Meta-data extraction: Explicitly explained why meta-data
          extraction from all draft formats is necessary.

       *  Meta-data extraction: be even more explicit that the validation
          procedure described in the following section may declare an
          extracted date invalid after taking into consideration current
          (i.e., submission) time, IETF draft expiration rules, and other
          factors external to the draft.  The validation section already
          has the necessary formal rules.

       *  Added R152 to require public availability of sources instead of
          just hinting at it (Henrik Levkowetz).  Explained that to
          meaningfully satisfy availability requirements, the Toolset
          cannot rely on unavailable software.

       *  Validation: added R153-R156 to require XML format and RFC 2629+
          DTD validation.  During the first two implementation stages
          validation failures result in warnings (not fatal submission
          errors) to give IETFers (and IETF tools) enough time to get
          accustomed to the necessity of obeying XML standards.  This
          addition documents Tools team consensus reached in December
          2004.  It should have been documented earlier.

       *  Polished SourceForge "hosting" hint to clarify that we are
          suggesting to place Toolset sources there and not suggesting
          that the Toolset runs from SF servers.

       *  Added Testing section with a hint: use existing drafts (Brian
          E. Carpenter)

       *  Terminology: replaced "WG draft" with "WG-named draft" or "WGN
          draft" because not all WG-named drafts are WG drafts and we do
          not want to deal with the difference or to answer questions
          about the "wrong" terminology.

       *  Overall operation: explicitly stated that the Toolset has to be
          compatible with the Secretariat's tools for handling drafts
          with a hint that such compatibility can be achieved by
          appropriately implementing the Toolset or, in some cases, by
          modifying existing tools.

       *  Scope: Addressed concern that "there should also be provision
          for those who prefer to use troff/nroff" by explicitly stating
          that the set of requirements in this document is not
          comprehensive and other documents may add more requirements,
          including those related to other source formats.  The Tools
          team in not interested in adding troff/nroff support to the
          Toolset, especially in this document.

       *  Applied Last Call comments by Frank Ellermann.

       *  Added a hint: The Toolset implementers should not assume that
          draft formats generated by the same tool from the same source
          format have essentially the same content (Keith Moore).

       *  Updated Acknowledgments section.
_______________________________________________
Tools-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-team

---

From: Larry Masinter <[email-masked]>
Date: Wed, 13 Apr 2005 13:57:53 -0700

I've been thinking about the discussion of TRoff, macro
processing, etc., and I wonder about the possibility
of allowing any author to optionally submit a single
file (or ZIP package of files) of whatever they consider
to be the "actual source" for the Internet Draft,
whether that's Word, nroff plus a macro package, XML
plus an XSLT style sheet, or whatever.

This "actual source" would be archived, made publicly
available, but not subject to any validation or
automatic processing. The derived XML and/or TXT
must also be submitted.

This would provide for archiving and allow others to
more easily create derivative works if they like,
but not make any promises about tools or automation.

What do you think? Was this already discussed and discarded?

Larry

---

From: "Alex Rousskov" <[email-masked]>
Date: Wed, 13 Apr 2005 21:51:38 -0600

Larry,

	I cannot find enough use cases for supporting opaque blobs. Whenever  
somebody is using something semi-standard like MS Word or nroff, they  
should probably write a small draft explaining how the Toolset should  
handle their data. This would be the "Right Way" to support other popular  
formats.

	Whenever somebody is using something custom (e.g., a Perl preprocessing  
script), the utility of making that custom thing public is nearly zero.  
IMO, we should avoid such undefined/untyped/unchecked/void* things if for  
no other reason than for design purity sake.

	Said that, if somebody feels strongly about it, they should write a draft  
standardizing a blob interface. Perhaps they would require one or two  
archival formats. Perhaps they can require a README file or even a  
Makefile as a part of that archive. Etc. etc.

	In practice, since it does not look like any of the Tools team members  
are eager to document alternative formats (including an opaque blob  
format), we probably have no other choice but to keep them out of  
Submission draft scope :-)

Alex.

---

From: Larry Masinter <[email-masked]>
Date: Wed, 13 Apr 2005 21:52:13 -0700

Alex, I don't think I was proposing "opaque" blobs, and I wasn't
proposing "documenting all semi-standard file formats".

I was proposing an open approach where the Internet Draft
authors can provide material that *they* believe will be
useful to others, along with instructions on how to use it.

That is, rather than waiting for some consensus that a format
*must* be recognized by lots of people before it can be submitted,
we go ahead and accept something, even if only ONE author
finds it useful.

What is the harm in accepting this additional material, if
it isn't normative and if the 'standard' formats (XML, TXT,
PDF, PS) are also provided?

Then we wouldn't have to argue about whether 'nroff' was
or wasn't useful to a lot of people. Authors that use
nroff can submit their nroff. If we get lots of nroff files,
we can try to standardize it and even accept it as an
'official' input format, but we need not.

Larry

---

From: "Alex Rousskov" <[email-masked]>
Date: Thu, 14 Apr 2005 23:03:04 -0600

> useful to others, along with instructions on how to use it.

That's an opaque (to the Toolset and similar tools) blob, IMO.

> PDF, PS) are also provided?

Confusion when contents do not match? Complaints from Mr. X that his PDF  
was rejected for auto-posting while Ms. Y's PDF was auto-posted as an  
opaque blob because Ms. Y cheated? Headaches of dealing with folks posting  
something secret by mistake (that the Toolset considered a part of the  
opaque blob)?

Some of these problems can be solved, but only with more work on our part  
and on the part of the Secretariat; without an indication that the  
resulting feature would be used enough.

> or wasn't useful to a lot of people.

I doubt those arguments will cease even if we accept nroff as an official  
IETF source format.

> Authors that use nroff can submit their nroff.

Why would they and how would they know that they can/should?

Thanks,

Alex.