Re: Roadmap on extensibility, registries, MIME (and MIME and the web Product Page)

Larry,

> Here’s another cut at establishing a framework for “MIME and the Web”
> product page which I could cut into the preface…
>
> I’m hoping this is stand-alone and “obvious” without additional context.
> Is it?

I think it's good work and important, but I think especially the early 
parts on terminology give more detail and less focus on success criteria 
for the effort than typically would belong in the product page itself. For 
the product page, what we need are short sections:

* Goals
* Success criteria
* Key deliverables
etc.

I think the Publishing and Linking page at [1] is a reasonable guide to 
style and scope for the product page.

So, I don't think we actually want to start the analysis and define terms 
on the product page itself. Rather, we want to >briefly< set out: Why are 
we doing this? What are we promising to deliver and when? When we're done, 
what impact should the work have in the community for us to consider it 
successful (success criteria).

I think the two paragraphs beginning with "There are a number of issues..." 
might be adapted to become a significant chunk of a goals section for the 
product page, but the earlier material seems to me to be more appropriate 
as part of whatever we actually produce as a deliverable.

Does that make sense? Thank you.

Noah

[1] http://www.w3.org/2001/tag/products/PublishingLinking.html

On 12/13/2011 2:57 PM, Larry Masinter wrote:
> Here’s another cut at establishing a framework for “MIME and the Web”
> product page which I could cut into the preface…
>
> I’m hoping this is stand-alone and “obvious” without additional context.
> Is it?
>
> As part of
>
> ·ACTION-595 “create a report on Mime and the web”
>
> ·ACTION-636 “Update product page for Mime and the Web”
>
> And likely relevant to
>
> ·ACTION-531 “Draft document on architectural good practice relating to
> registries”
>
> ·ACTION-350 “Revise .. (references to evolving specs) “
>
> ·ACTION-611 update http://www.w3.org/standards/webarch/protocols
> <https://www.w3.org/2001/tag/group/track/actions/611> .
>
> ============================
>
> *Evolution the web, and the role of Registries and MIME*
>
> An understanding evolution in the web needs careful distinction between
>  concepts; for this discussion, the following terms are used:
>
> ·*Protocol: *a way in which parties interact.
>
> o*Language: * a particular means of interaction by which (using a
> *protocol*) one party sends some data which is then interpreted by the
> receiver.
>
> o*Protocol element:* a small packet of information exchanged in a
> *protocol* or used in a *language* where the meaning of the protocol
> element in that context is described independently.
>
> ·*Implementation:* a software agent implementations may use protocols to
>  interact with other agents on the network, and may either read or
> produce content in one or another *language*.
>
> ·*Standard: *in this context, *standards* are technical specifications
> which describe *protocols*, *languages*, or *protocol elements*, and
> rules for how *implementations* of them are expected to behave.
>
> Evolution involves evolution of all of these things in a coordinated
> fashion:
>
> ·*Protocols*, *languages* and *protocol elements* evolve as
> *implementations* of them evolve and are used.
>
> ·*Implementations* evolve as their implementers of them create or adopt
> new features; in many cases, that evolution requires evolution or
> addition to the *protocols*, *languages* and *protocol elements *the
> implementations use to communicate.
>
> ·*Standards *evolve as the specifications evolve or extended, both
> leading *implementations *(proposing additions or changing) and
> following implementations where the standard is changed to match
> implementation behavior.
>
> The value of the Internet and the Web is global communication among
> unrelated parties. Different implementations need to agree on the
> protocols, languages, and protocol elements in their communication for
> them to interoperate.
>
> A *standard *can allow and promote evolution is to allow for
> extensibility in some of the *protocol elements* – the ability to add
> new values for them that were not part of the protocol or language at
> the time the standard was written. There are a variety of ways in which
> this can happen; one commonly used way a standard can allow this kind of
> evolution is by using a *registry*.
>
> A *registry* is a list, maintained by an organization or individual,
> which lists values of a *protocol element *and the meaning of that
> protocol element in the context of the *languages *or *protocols *that
> use it.
>
> *MIME *is a framework for transmitting content within *protocols*; one
> of its most important features is its system of naming *languages
> *(“Internet Media Types”, informally known as MIME types.) In
> particular, there is an Internet Media Type *registry*.
>
> The “content-type” protocol element (used in the web and email) contains
>  the name of a *language *(its /Internet Media Type/) and some
> parameters; those parameters include a “charset” *protocol-element*.
>
> HTTP is a *protocol. *RFC 2616 is a *standard *that describes it. RFC
> 2616 allows transmission of data in a *language*; in that transmission,
> the language by which the data is to be interpreted is given by the
> “content-type” protocol element.
>
> HTML is a *language*, the primary language used in the web. Other
> “languages” used in the web are JPEG, GIF, CSS, etc.
>
> As the web has evolved, the *registry* for the Internet Media Type
> *protocol-element *has not kept up with the *implementations* and use
> within browsers and the HTML language.
>
> There are a number of issues that need to be addressed to help achieve
> the goal of careful evolution and global interoperability in an evolving
> world. Those recommendations include attention to the way in which
> *standards* allow for extensibility by adding values and new meaning to
> their *protocol elements *used within them, guidelines for establishing
> and using *registries*, and a clearer model for evolution in a way that
> a standards organization can lead in the managed evolution of the
> technology available to its implementations.
>
> **
>
> There are a number of alternatives and considerations for how
> extensibility is managed in standards within W3C and IETF that will be
> examined:
>
> ·Extensibility and choices for allowing extensibility in otherwise
> stable standards.
>
> ·Consideration for use of registries.
>
> ·Guidelines for use and maintenance of the MIME registries.
>

Received on Tuesday, 13 December 2011 22:36:59 UTC