when HTTP is not available

Graham Klyne wrote (quoting me quoting him)

> >> In summary, I am content with this IFF it is stated separately from feature
> >> set syntax extensions.
> >
> >I think I disagree here. This seems to me to be an appropriate
> >requirement, even if we end up treating syntax extensions and
> >mechanism as a single monolithic extension to the standard. As I see
> >it, it's not just useful to have some common mechanism defined, it's
> >vital.
> 
> I envisage deployments where http is simply not available.
> 
> >I can imagine scenarios where it's not appropriate to support "http:"
> >URLs, but they're obscure scenarios.
> 
> Angonamo!  I've not argued for not supporting http: URLs.  I've only argued
> for not requiring HTTP resolution in all cases.  As I type this, I do not
> have a live Internet connection;  for e-mail based applications, I believe
> that mechanisms that do not depend on continuous Internet connectivity are
> appropriate.  I do not believe this is an "obscure" scenario.

"Obscure" was the wrong word -- I don't know a really good word. (And
speaking of my inadequate vocabulary, what's "Angonamo"?) In my view,
using URLs to represent feature sets is a good thing for an RFC
to address, because
  1. It addresses a problem that we have reason to believe lots of 
     people (users of mobile devices with slow Internet connections) 
     will care about (reducing a possible multi-second delay
     to transmit a feature set over a wireless link by a factor
     on the order of 10).
and
  2. We know enough about the problem that we can write a spec 
     which solves the right problem, which supports interoperation
     without adding an unacceptable amount of deadweight for people
     who don't care about the problem.
while requiring HTTP to be available is good because
  3. People who follow the spec can can expect their applications to 
     interoperate reliably with applications written by other people 
     they've never met.
I'm not aware of any can't-use-HTTP scenarios for using grouped
feature sets which are good in the same way. So what I really wanted
to say is something like "lacking the characteristic of satisfying 1,
2 and 3". For whatever reason -- perhaps since I've been led to
believe that such scenarios are relatively low priorities in the IETF
-- it came out "obscure". It's not that it's rare for computers not to
have HTTP -- mine was offline when I wrote this, too.  It's that it
seems rare for them to not have HTTP, need interoperable content
negotiation, need interoperable feature set grouping, and be standard
enough that we can reasonably address their need for interoperability.

The one class of cases that I can think of which might want something
like this involves some centralized feature set repository/registry,
as was discussed some time ago. I'm skeptical about the practicality
of a universal repository. I can see that a centralized registry could
be practical in a limited domain, but I'm not convinced it's an
important role of RFCs to define standards which are only applicable
in a limited domain -- I consider this to fail on points 2 and 3
above.  In my view, once you've decided to limit your communications
to people who've agreed, out of band, to some specialized information
(here a feature set repository/registry), you've basically lost
interoperability already, and there's no reason you can't get them to
agree to some specialized variant of the RFCs, too.

All that said, I should also say that I'm nonetheless becoming more
receptive to the idea of splitting the proposal into two layers. I'd
been resisting this idea because I thought that the first layer of
syntax without mechanism wouldn't let anyone actually write
applications which interoperate reliably, which is what I like IETF
standards to do. I still think that. However, thinking about how there
will be scenarios in the future which we can't anticipate now, I can
now see that there's value in writing the standard in such a way that
future standards addressing new scenarios have an appropriate
jumping-off point, sharing as much as possible of the old standard
(the syntax) while redoing the transport issues to address the new
problem. So separating this proposal into two layers is good because
  4. It makes it easier to use this specification as the basis for 
     for future specifications to address new problems.
It's still not clear to me how much document complexity is justified
in order to support this in this particular case, but at least I can
now appreciate that it's nonzero.

  Bill Newman
  [email protected]