[BXXPwg] SOAP over BEEP

Bill Mills wmills@invisibleworlds.com
Mon, 18 Jun 2001 14:20:35 -0700


I don't know if I like it as much but what about 

	beep://foo.com:<profile>:<port>:<proto>/

This would allow us to stay near the current usages for URL's.  It has
the disadvantage of significantly overloading the current usage for port
specification in HTTP.

Again I think the ugliest thing here is if we end up needing a full 
URL to identify the profile.

-bil

-----Original Message-----
From: Eamon O'Tuathail [mailto:eamon.otuathail@clipcode.com]
Sent: Monday, June 18, 2001 2:03 PM
To: Bill Mills; bxxpwg@lists.invisibleworlds.com
Subject: RE: [BXXPwg] SOAP over BEEP



The idea of a superhandler would be neat, but ...

from a practical viewpoint, having multiple ':' could well trip up
many generic implementations, and

>From a standards perspective, RFC 2396, states:
   "Many URI include components consisting of or delimited by, certain
   special characters.  These characters are called "reserved", since
   their usage within the URI component is limited to their reserved
   purpose.  If the data for a URI component would conflict with the
   reserved purpose, then the conflicting data must be escaped before
   forming the URI."

      reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                    "$" | ","

and later:
   "Within the authority component, the characters ";", ":",
   "@", "?", and "/" are reserved."

You don't have to follow the "scheme>://<authority><path>?<query>"
approach - but the vast majority of implementations do.

   "The URI syntax does not require that the scheme-specific-part have
   any general structure or set of semantics which is common among all
   URI."

The BNF in RFC 2396, appendix A does permit use of ':' in the opaque_part.

The more you stray from what people expect, the more likely things will be
broken.

Eamon