Re: when HTTP is not available

At 12:34 06/03/99 -0800, Bill Newman wrote:
[...]
>> >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"?)

It was a way of introducing a challenge (say it out loud, it's not a real
word).

> In my view,
>using URLs to represent feature sets is a good thing for an RFC
>to address, because

I have no argument with that statement.

>  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".

I don't wish to prevent you imposing any constraints you like in the
scenarios that are important to you.  But I don't see that those
constraints should be imposed on all scenarios.  That is why I argue for
separate document dealing with representation and resolution mechanism.

One specific scenario that interests me is Internet fax, a significant
application, and I cannot see why Internet fax systems should be required
to implement http if they have other useful mechanisms available for their
purposes.

>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 not assuming that.

>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

That is really at the heart of my position.  In this we are fully agreed...

>  4. It makes it easier to use this specification as the basis for 
>     for future specifications to address new problems.

Yes!

>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.

I'd hope that the document complexity increase (not counting
twice-boilerplate as complexity) will be modest:  some clear cross-document
citations, I think.

#g

------------
Graham Klyne
([email protected])