On Fri, 19 Sep 2003, Anwar M. Haneef wrote:
Please let me know if there are any better ideas or objections. We
still need to investigate what HTTP module URI should look like from
IETF point of view. The same info is needed for OCP: we need URIs to
identify message parts and other negotiated features.
Why do we want to restrict the URI for importing HTTP modules in
case we allow this to be interpretor implementation dependent ?
Again, why the same for OCP messages as well ? I think I am missing
something here. Please advise.
I am probably not expressing myself clearly. URI in this context is
just a well-known or standard "name".
As a rule writer, I need to know how to tell the interpreter that I
need to import a well-known HTTP module. I need to know a URI that all
P interpreters out there will treat as an "HTTP module (RFC XXX)
identifier". The URI is _not_ interpretor implementation dependent.
The URI will be documented in the HTTP module RFC (when somebody
happens to write that document, of course).
Same for OCP messages: the other side needs to map the URIs I am
sending in negotiation messages to particular things it knows about,
like SMTP message parts or services.
For all this to work, we have to document every "standard" URI (name)
somewhere. What I am not sure about, is what scheme, domain, and path
to use for those standard URIs. I assume they would need to be
registered with IANA (to avoid conflicts with other standard URIs). I
suspect IETF has some RFC that suggests appropriate URI format and
registration process. I did not investigate this yet though.
This is similar to URIs XML folks are using to identify their
namespaces. For example,
<html xmlns="http://www.w3.org/1999/xhtml"; lang="en-US">
Does this clarify?
Alex.