I have got this copy of Jacob Palme's (Sweden) personal notes from
the IETF meeting last week. It gives his view on the meetings
that he attended, which covers I believe all the meetings of
the Applications Area, including our own BOF session.
I have known Jacob for many years and know that he is pretty good at
writing reports from meetings of this kind (he is also the author of
several detective stories), so I thought it might be enlightening for
all of us to see this.
I include only the parts reporting about the introductory meeting,
our printing BOF meeting, and the fax BOF meeting in this message,
but encourage you to retrieve the whole text from Jacob's Web page.
I expect that Jacob's report will be widely read in Europe.
Carl-Uno
>Notes from the applications area at the IETF meeting in
>San Jose, December 1996.
>---------------------------------------------------------
>
>A neater version of these notes can be found at URL:
>http://www.dsv.su.se/~jpalme/ietf/san-jose-96-notes.html
>
>This was the largest ever IETF meeting, more than 1600
>participants. There was a discussion on the IETF list how to
>make effective progress with so many participants. The man
>who opened the IETF meeting said that of those who came to a
>subgroup, those who were really active in the subgroup should
>sit up front, and other visitors should give way.
>
>I noted that several friends whom I had earlier met at ISO
>and ITU standards meetings were present at the meeting, for
>example Bengt Acksell and Carl-Uno Manros. I think it is
>valuable that people with ISO/ITU background participate in
>IETF work. They have a lot of experience which can be of
>value to IETF.
>
>A very few participants had portable computers with cellular
>phone connections, to give them on-line connections in the
>middle of the meetings.
>
>These notes were mostly written during the ongoing meetings,
>with a portable computer noting down what people said. This
>mean that the text in the notes may sometimes not be as
>coherent as in a carefully prepared exposition on an issue.
>Opinions below are not necessarily my own, often I have just
>written down what someone said. I may have misunderstood
>certain things, I have not checked this text with the people
>responsible for the reported standards work.
>
>Several of the sessions discussed applications where a good
>directory system might be useful, but Harald T. Alvestrand
>warned every time, saying that directory systems is a
>*rathole*. I guess he meant that little success has been made
>in this area despite many years of work, and that if you want
>to define successful standards you should use solutions which
>do not depend on directory system support.
>
>A general impression of the U.S.A. is how identical the ideas
>and thinking here and in Europe is on social and political
>issues. The "dust bin" on the computer desktop is for example
>being renamed "recycling bin" (which really is much more
>adequate, since disk space freed can be reused for other
>files when you empty the "recycling bin".)
>
>Introductory speech to all participants
>---------------------------------------
>
>If you have proposals for nominations to the IETF board,
>write e-mail to:
>nomcom@telstra.net
>
>Network management and operations are jointed into one area.
>
>Requirements for Internet Standards:
>- Standards must support global Internet
>- High demands for generality, clarity, scalability and
> deployability.
>
>IESG will review all documents for RFC publications, not only
>standards, in the future. There must be a high technical
>quality (see RFC 2026).
>
>WG requirements:
>- Don 't reinvent technology (this also applies to technology
> specified by other standards organizations).
>- Be aware of other concurrent activity, so as not to
> duplicate work. There is a problem sometimes with too much
> creativity in standards development.
>- Charter should include justification, cite prior art (what
> is meant by that?) and prior activities.
>- No research! Some existing working groups are more
> research than standards work and should move to other
> organizations than IETF.
>
>Architectural consistency:
>We all share responsibility for architectural consistency. Do
>not specify multiple ways to do the same thing. Avoid
>conflicting objectives.
>
>Restrictions on document titles:
>- Truth in advertising!
>- Limits on names for informational and experimental RFCs:
>- No "Requirements for xxx" in the title of an informational
> RFC. "Recommendations" or "Considerations" are better
> words.
>- Not: "the Internet xxx" or the "xxx" but "Fred's xxx".
>
>RFCs should be clear as to who their intended audience is:
>- designers
>- implementors
>- operators
>- help desk people
>- end users
>- other
>
>i18n: Internationalization; Internet is not U.S. only, not
>English-only, MAIL TO is not POST TIL.
>for new protocols:.
>- use ISO 10646 as default coded character set
>- use UTF-8 as the default character encoding scheme where
> ascii compatibility is required (RFC 2044).
>- exception for some universal identifiers which use ASCII
> subset of UTF-8.
>
>Note: UTF-8 is an encoding scheme for ISO 10646, such that
>US-ASCII characters are encoded identical as for ordinary US-
>ASCII.
>
>Configurability:
>- options increase complexibility and decrease
> interoperability.
>- options should not be added to satisfy some noisy
> minority.
>- may be best to put options in separate documents.
>- must specify defaults for options.
>- security checking must be enabled by default.
>- but thinking about future extensibility is good.
>
>Intellectual property rights (IPR):
>- Do not push an idea in which you have an interest
> without disclosing that interest.
>- RFC 2026 permits standards which have IPR.
>- IPR can show up late and from outside the IETF.
>- If there is IPR, then the multiple implementations needed
> for standards must be from different licensees, not the
> same company.
>
>Options which no one implements must be removed from a
>standard. Working group chair must document implementation
>experience, including which options are really implemented.
>
>Important: the basic IETF work takes place on mailing lists,
>not at face-to-face meetings. These mailing lists must be
>open. Some people might disrupt discussion, and it might in
>rare cases be necessary to prohibit someone from
>participation. But this should be very rare and need approval
>from the area directors.
>
>Security considerations must be real. The phrase "Not
>considered" is not acceptable in the security considerations
>section. Discuss security assumptions behind protocol
>changes, security impacts, environment where the protocol is
>to run, list known threats. Example: When to allow clear text
>passwords.
>
>Well-known constants:
>IANA can register constants & tags
>If this is needed, an "IANA considerations" section in the
>RFC is needed
>
>Draft standards must include network management issues. If
>management is not needed, this must be explained. Current
>standards management protocol i SNMPv2, you must ensure you
>are compatibility with this.
>
>Scalability: Success is a problem. State limitations on scale
>of use. Discuss: "can it scale to tens of millions of users"?
>Include all limits (round trip, computing resources,
>symmetry, etc.).
>
>Applicability: What is it for, how does it relate to existing
>protocols, arena of use (LAN, AS, Internet).
>
>Network stability: What happens if the network goes down?
>Note any particular problems. Robustness. Topology problems.
>
>
>Internet printing application
>-----------------------------
>
>A BOF was held to start up an IETF working group on Internet
>printing, i.e. how a client can contact a printer through the
>Internet and have a document printed.
>
>The group was headed by Carl-Uno Manros, previously a leading
>developer of OSI standards, and the group plans to develop a
>standard using the OSI DPA (Document Printing Application) as
>a basis. This is an interesting tendency, which we will
>probably see more of, where developers of OSI standards will
>want to convert their standards to IETF standards. One could
>feel a certain skepticism in the group from IETF veterans.
>
>The group will however not copy directly the OSI functions.
>The new protocol will be simplified to only contain the most
>important functions, it will use ABNF encoding methods, not
>ASN.1, and it will be based on using existing Internet
>protocols to a large extent. In particular, HTTP will be used
>as the protocol to communicate between user agent and
>printing server. User control of printing, like locating
>printers, checking their capabilities, submitting print jobs,
>checking print queues, canceling print jobs, etc., will be
>performed using ordinary web browsers and HTML form based
>user interfaces. But they also planned to download printer
>drivers from the net to the personal computer of the user. I
>did not quite understand what was to be done by special-
>purpose clients (printer drivers) and what was to be done
>using ordinary web browsers.
>
>The work was supported by an impressive number of
>manufacturers of computers and printers, like IBM, Lexmark,
>Canon, Xerox, etc.
>
>IETF drafts are already available specifying user
>requirements (draft-wright-ipp-req-00.txt) and a first
>protocol draft (draft-isaacson-ipp-info-00.txt).
>
>
>Fax over the Internet BOF
>-------------------------
>
>Goal: To be able to communicate to or from ordinary fax
>machines via the Internet. Mainly sending fax via the
>Internet but doing the final delivery via fax, although other
>architectural combinations are possible.
>
>Two main modes: Store-and-forward, via e-mail, the whole
>message is stored before it is delivered. This is the primary
>objective of the group, and the primary storage method in
>this mode will be TIFF-F, which is a variant of TIFF
>specially designed for fax.
>
>Another mode, called streaming, means that, just like for
>ordinary fax machines, you are transmitting and printing
>without even waiting for a whole page to be read. In this
>mode, TIFF-F does not work, since it requires a page count
>before the document is sent.
>
>There are various intermediate possibilities between store-
>and-forward and streaming.
>
>There also seemed to be agreement that machines which
>transmit to fax machines should be able to handle text/plain.
>Of course many products will be capable of handling many more
>formats. Which character sets?
>
>There is a possibility that TIFF-F has intellectual property
>rights such that IETF cannot use it. This must be clarified.
>
>One thing I learnt was that fax is not 200 BPI horizontally,
>it is 204 BPI horizontally. And vertically, it is not 100 or
>200, it is 98 or 196.
>
>------------------------------------------------------------------------
>Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
>for more info see URL: http://www.dsv.su.se/~jpalme
>