Re: when HTTP is not available

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




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