RE: First reactions to mandatory draft

Numeric perfixes aren't to allow multiple instances of the _same_ extension
in one message -- they are to guard against the possibility (to use your
example) that two independent parties design an extension, and both call it
"Skidoo" (but they will have different URLs for the extension, of course),
and still allow both to be used in one request.

I think it shouldn't be optional, and the proposed solution is even more
complicated than supporting perfixes.
> ----------
> From: 	Scott Lawrence[SMTP:lawrence@agranat.com]
> Sent: 	Tuesday, January 20, 1998 7:15 AM
> To: 	Rohit Khare
> Cc: 	frystyk@w3.org; Paul Leach; ietf-http-ext@w3.org
> Subject: 	Re: First reactions to mandatory draft
> 
> 
> >>>>> "RK" == Rohit Khare <rohit@bordeaux.ics.uci.edu> writes:
> 
> RK> Scott LAwrence wrote:
> >> If your intent is to allow me to define an extention that uses a
> >> "Skidoo" header and then at run time decide that today I'm going to
> >> send it as "23-Skidoo" then I think that is taking flexibility too
> >> far.  If I'm adding support for an extention to my product, then I
> >> want to know what headers it uses and just write code to recognize
> >> them; not have to make the parser so general that it can strip and
> >> ignore prefixes on the fly that may be different in each request.
> 
> RK> That's what it comes down to: how dynamically do we envision these
> RK> extensions being added to systems? In short, can we expect an
> RK> admin to drop in two versions of a Skidoo-handling extension that
> RK> may both want to operate on the message. [...]
> 
> RK> There is no requirement for numeric-prefixes, of course.  It's
> RK> just an option.  But, options have a cost, too, I'll grant.
> 
>   I discussed this by phone with Henrik a week or so ago, and promised
>   him some revised text to address my concerns here.  Essentially, I'd
>   like to clarify that the use of the numeric prefix mechanism is
>   optional, and add a response indication from the server to
>   communicate that while it may understand the proposed extention, it
>   does not implement the ns= mechanism so that the request must be
>   resent without it.
> 
>   I'll try to get that text out this week.
> 
> --
> Scott Lawrence           EmWeb Embedded Server
> <lawrence@agranat.com>
> Agranat Systems, Inc.        Engineering
> http://www.agranat.com/
>

Received on Tuesday, 20 January 1998 14:20:02 UTC