Draft text: The Core Feature Set (Sections 1 - 4)

We (meaning Andy Mutz and me) have been working among ourselves for
some time on feature tag registration and on the core feature set.
See

http://gewis.win.tue.nl/~koen/conneg/draft-holtman-http-negotiation-03.html#8

for some background. Here is some draft text we have come up with.  We
plan to put this text into a future `core feature set' internet draft.
Please send comments to the list.

Unresolved issues are marked [##like this##].  We need the help of
Java/javascript experts to finish section 4.

Koen.

---snip---

     The Core Feature Set (Sections 1 - 4)
     =====================================

1. Introduction

 In order to provide a useful set of feature tags as a starting point
 for the deployment of feature negotiation, this document proposes a
 core set of feature tags.  This set mostly covers areas of
 negotiation which are currently stable and well understood.

 This set is not meant as a complete or exhaustive list of useful
 feature tags.  It is intended that user agents which implement
 feature negotiation should at least recognize all core feature tags
 which represent features they implement.


2. Notation

 This document uses short feature tag descriptions, as introduced in
 [##Section C.2 of the `Feature Negotiation Notation Conventions'
 text##], for describing the feature tags in the core feature set.

 To register the core feature set in future, these short descriptions
 will have to be expanded to filled-in feature tag registration forms.
 Feature tag registration will be defined in a separate document.

 If no detailed or authoritative textual definition of a feature is
 publicly available, the exact functionality indicated by a feature
 tag can be defined by pointing to a `reference implementation' which
 implements the feature.  This reference implementation usually is the
 first non-beta user agent which implemented the feature.


3. Tags related to handling of HTML documents

 [##Note: Most of the tag descriptions in this section are based on my
 reading of WD-html32-960909##]


3.1 General

 html=version

   Indicates support for the given HTML version.  Predefined values
   are 1.0, 2.0, 3.2.  Example: Accept-Features: html=2.0, html=3.2, *


3.2 Tags related to HTML 3.2.

 These indicate specific elements of HTML 3.2 which may not (yet) be
 supported by some 3.2 browsers, or which may already be supported by
 some 2.0 browsers.

 html_ol_start

   Indicates support of the OL START attribute, which initializes the
   sequence number of an ordered list.

 html_ol_type

   Indicates support of the OL TYPE attribute, which sets the
   numbering style for an ordered list.

 html_dir

   Indicates that a DIR list will be rendered as a multicolumn
   directory list, and not in a way similar to an UL list.

 html_menu

   Indicates that a DIR list will be rendered as a single column menu
   list, and not in a way similar to an UL list.  [##I got this
   language from the 3.2 draft.  Does it mean `no bullets in front of
   the elements'?##]

 html_img_usemap

   Indicates support for client-side image maps, with MAP elements in
   the same document.

 html_img_usemap_external

   Indicates support for client-side image maps, with MAP elements in
   the same document or in an external document.


3.3 Tags related to HTML forms

 form_mailto

   Indicates that a form with a `mailto:' action URL can be handled.

 form_file

   Indicates support for the <INPUT TYPE=FILE ...> form field for
   attaching files to the form content, and the associated
   encoding mechanisms described in RFC 1867.

 form_enctype=mime-type_tokenized

   Indicates a capability to use a form content encoding other than
   application/x-www-form-urlencoded.

 form_file_accept

   Indicates support for restricting the MIME type of files attached
   to the form content with the ACCEPT attribute.


3.4 Tags related to HTML tables

 tables

   Indicates support for all TABLE markup tags and attributes as
   defined in HTML 3.2, except the the BGCOLOR attribute in TH and TD
   table elements.

 table_bgcolor

   Indicates support for the BGCOLOR attribute in TH and TD table
   elements.

 tables_ns20

   Indicates support for all TABLE markup capabilities which are
   present in NetScape 2.0 [##Was 2.0 the first version with
   tables?##].  [##Do we need this? I don't know. I believe it would
   indicate support for a subset of 3.2 tables.##]


3.5 Tags related to HTML frames

   TBS.  Also put in tags about frame navigation capabilities?


3.6 Miscellaneous

 css=version

   Indicates support for a particular version of cascading style
   sheets (CSS).  For example: Accept-Features: ccs=1, *.

 [##link##]

   [##The 3.2 spec says that most browsers still ignore LINK tags.
   One or more feature tags could indicate support for (various parts
   of) the LINK tag semantics, but I don't know enough about LINK to
   invent such tags.  Roy?##]


4. Applet and scripting support

 java

   Indicates support for Java applets.

 [##There probably need to be some tags for negotiating on java class
 libraries (something like java_classlib=library_name_and_version).
 Though the language itself seems to be stable, there is some
 divergence and marketplace competition in the libraries,
 e.g. Netscapes Internet Foundation Classes.  A java expert is needed
 to invent some meaningful tags here, the current authors are both no
 experts in this area.##]

 javascript_ns3.0

   Indicates support for the Javascript features present in NetScape
   3.0.  

 [##The current authors know little about javascript versions.  Some
 background information from Andy Mutz:

  From what I CAN see, Netscape 3.0 has not put out much documentation
  on Javascript implementation.  There is a difference between
  implementations based on the browser.  Best bet might be
  javascript=ver?  Microsoft IE3.0 has "JScript" to work around this.
  To quote from the newsgroup comp.lang.JavaScript:

  Javascript is *proprietary* Netscape code. Netscape hasn't released
  any specs on it to the outside world, and Netscape controls the
  language. Microsoft attempted to implement a form of Javascript for
  IE3, based only on the little bit of documentation that Netscape
  provides.

 Again, a javascript expert is needed.
 ##]


[##Current plans for additional sections include:
- Tags related to output devices and preferences
- Tags related to transmission and rendering delays
- Tags related to user agent bug negotiation
##]

--snip--

Received on Thursday, 3 October 1996 05:18:57 UTC