Subject: Re: when HTTP is not available

From: Graham Klyne <[email-masked]>
Date: Mon, 08 Mar 1999 13:47:06 +0000

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-masked])

---

From: Ted Hardie <[email-masked]>
Date: Mon, 8 Mar 1999 11:35:21 -0800 (PST)

Bill, Graham,
	I personally believe that splitting the proposal allows us to
standardize a single syntax and propose a number of different
resolution mechanisms, with different mechanisms appropriate to
different applications.  I think that will make adoption of the syntax
more general.  It is, of course, too late to produce a two-layer
proposal prior to the Minneapolis IETF, but it might be helpful if you
could identify in slide form which bits are likely to go where.  That
will help us focus discussion in the working group meeting, and I
think we might well be able to come to a quick consensus on that.
			best regards,
				Ted Hardie