Re: Application "core protocol" BOF/WG idea

Chris,

At 12:20 29/01/99 -0800, Chris Newman wrote:
>On Fri, 29 Jan 1999, Graham Klyne wrote:
>> Specifically, I find the idea that we can "design a simple core protocol to
>> address these problems" is something of a tall order.
>
>You may be right.  But what if we can?  Just because it might be hard does
>that mean we shouldn't try?

I wouldn't say we shouldn't try "just because...".  (I might argue that
given a choice between useful goals, I'd pick one more likely to succeed.)


>I'll note one ad-hoc attempt at such a "core protocol" was published as
>draft-earhart-ap-spec-01.txt (January 1998).

Scanning through that, and re-reading your original proposal message, has
helped me to focus some issues.  I don't think our views are miles apart here.

A passage from "draft-earhart-ap-spec-01.txt" particularly struck me:

   It is recognized that not all application level protocols will fit

into this model; TELNET is a good example of a protocol that does not

belong in this framework.  Nevertheless, it is believed that this is
   of
sufficient utility to enough protocols to be worth advancing as an
   IETF
standard.

For me, this begs the question:  what are the characteristics of these
"enough protocols" for which such a framework is maybe "of sufficient
utility"?  You have already enunciated part of the answer I was seeking:
"based on the connection-based stateful client-server structure ..."

What are the key components of "draft-earhart-ap-spec-01.txt"?  I perceive:

(1) a "session state" model dealing with initiation, authentication,
termination and application-specific states.
(2) a framework for declaring server capabilities
(3) a request/response framework, with tagging to allow overlapped operations.
(4) a framework for unsolicited status updates
(5) some syntax elements for construction of requests and responses,
including some formats for simple and structured data
(6) some core capabilities, request verbs, response codes

In my view, this could be seen as a small number of separate work items:

(a) a small core protocol document could cover (2)-(5).

(b) A separate document could cover the basic initiation and authentication
framework, associated server states, request verbs, response codes, etc.

(c) A guidelines document could describe how to build application protocols
using (a) and (b), together with other considerations that should be
addressed by a protocol specification.  (I think this could usefully draw
upon your -protocol-design- document.)


Some additional random thoughts I have:

- It would help if there were clear mechanisms for transferring MIME
objects with both requests and responses.  On my brief scan, it's not clear
how to do this with the -ap-spec- framework.  (I don't mean to necessarily
adapt the protocol for MIME specifically, just make it clear how MIME (and
maybe other arbitrary objects) are transferred within the overall framework.)

- If each application protocol based on the framework were identified by
its own capability, any server would automatically be completely
self-identifying in that respect (see also section 6 of -ap-spec-).

- Should the request framework have any explicit provision for using URIs
to identfy objects?

- I'd personally like to see a development of the RFC 1893 status code
framework for more widespread use (providing language-neutral status
indicators).

- I do think that there are some issues of interaction beytween server
state and overlapped requests that must be carefully considered (or flagged
for application designers to carefully consider).  E.g.  what happens if a
LOGOUT is presented while some other command is being processed?


To summarize:

In practice, I don't think a core-protocol plus application-specification
would be a complete application protocol definition.  References to other
components (e.g. MIME, TLS, SASL, RFC1893, S/MIME, etc.) would, I think, be
the norm.  This is the respect in which I saw protocol components being
important;  I now perceive that you did not mean to exclude this, just not
take these other protocol elements into scope.  I would still like to see
some separation of concepts in the core components, as indicated above, but
not fragmentation.

In preparation for undertaking such a design, I do think it would be
helpful to enumerate some commonly-used current application protocols and
note their strengths and weaknesses in practical deployment.  I also think
that work from other groups like the HTTP NG effort should be examined for
suitability before embarking on yet another protocol design effort.

I hope you find this constructive,

#g


------------
Graham Klyne
(GK@ACM.ORG)

Received on Monday, 1 February 1999 14:17:23 UTC