Subject: [Simple] XCAP URI Scheme?

From: Aki Niemi <[email-masked]>
Date: Wed, 11 Aug 2004 16:36:29 +0300

Hi All,

This came up in the past in terms of whether or not XCAP is a new
protocol based on HTTP or not. I think we are clearly talking about
HTTP, but there is I think another aspect to this.

Where a new xcap URI scheme would be very beneficial would be in guiding
a non-XCAP application in deciding which application to dispatch for the
URI. For example, if included in a web page, or email message, with an
xcap URI the client could be configured to dispatch an XCAP client
instead of the default for http, which is usually just a web browser.
GETs would still (kind of) work without an xcap URI, but in order to do
anything more elaborate, the client really needs to understand XCAP. (in
fact, there would need to be even a second level of dispatch based on
AUID, but that's a separate issue.)

The schema really would be just for this purpose of dispatching, and
abstract in a sense, since the XCAP client would handle the URI simply
by replacing the "xcap:" with "http:". 

Having said that, I don't know how well such a thing would merit
defining a new URI scheme. It also seems that the process for defining
new URI schemes is not the most straight forward - even though in this
case the actual definition would be a trivial one.

Thoughts?

Cheers,
AKi

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Aug 2004 14:17:56 -0400

I do not think we should define a different URI scheme for XCAP.

An XCAP resource *is* an HTTP resource. If you got an HTTP URI in a 
context in which you didnt understand what to do with it, performing a 
GET does the right thing - it gets the content.

The problem you are worried about is that there is context above HTTP, 
in knowing that the resource you are getting has some specific meaning - 
its a buddy list, or a CPCP document. You have this kind of issue with 
any http content that is processed by an automata, as opposed to a 
human. I think that, generally, the context is provided by the 
application that passes around the URI. That is, if a phone has a 
configuration profile that tells it to follow a certain URI to get its 
buddy list, then the fact that the URI is coming from a specific field 
in the configuration provides the context.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Dave Cridland <[email-masked]>
Date: Fri, 13 Aug 2004 22:09:42 +0100

On Fri Aug 13 19:17:56 2004, Jonathan Rosenberg wrote:
> context in which you didnt understand what to do with it, 
> performing a GET does the right thing - it gets the content.
> 
> 
I agree with you in as much as an XCAP resource "is a" HTTP resource, 
in as much as that usage is in agreement with the usual OO 
terminology. It's not in doubt, either - it's the reverse that isn't 
true, and is a problem.

This is starting to become a pressing problem - it's already 
impossible for me to take a "web folder" (ie, WebDAV) URI and drop it 
in an email, expecting the user's MUA to dispatch it to the right 
application. It'll pick the wrong one, a web browser, usually. I was 
under the distinct impression this was the point of URIs.

With XCAP, I entirely understand that the URI is unlikely to be used 
in this way except by between knowledgable users, given its limited 
scope.

Creating new URI schemes isn't really the answer, I think - we need 
some other additional, backwards compatible, method for indicating 
it's XCAP (Or WebDAV, or any of the 37,576 protocols now built on top 
of HTTP). For XCAP, document fragment identifiers would work, given 
that they're not used for XCAP. In general, an illegal fragment 
identifier might be best - #? for instance. I've no idea what current 
applications might do with a double fragment identifier, though.

Dave,

---

From: Aki Niemi <[email-masked]>
Date: Mon, 16 Aug 2004 10:55:25 +0300

> in the configuration provides the context.

Yes, this is fine as long as the URI comes with a specific context, as
in part of configuration information. For many XCAP AUs (like the buddy
list) this is the norm, but imagine a web page that contains information
about a conference bridge. Standard HTML markup like this:

<a href="http://xcap.example.com/services/conference/~~/blah">Conference
Policy</a>

will not give enough of a context for the browser to do the right thing
were a user to click this link.

<a href="xcap://xcap.example.com/services/conference/~~/blah">Conference
Policy"</a>

then again would. It could dispatch an XCAP client instead of just
displaying the XML file that a GET to this link would return. 

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Mon, 16 Aug 2004 16:26:38 +0300

> applications might do with a double fragment identifier, though.

Perhaps you're right about the new URI scheme - I'm open to any solution
that works. However, I don't think fragment identifiers would work,
since AFAIK, they are supposed to be interpreted only *after* document
retrieval, which is already too late.

Of course the MIME type of the XCAP resource (e.g.,
application/resource-list+xml) already serves as an identifier, but
there is no guarantee that in the absence of a configured helper
application for such a MIME type, the browser wouldn't simply render the
XML to the user. In fact, I think it even SHOULD. Compared to not doing
anything at all when a user clicks the link, I think this would be worse
user experience. Not by far, but still...

Cheers,
Aki

---

From: Dave Cridland <[email-masked]>
Date: Mon, 16 Aug 2004 16:02:40 +0100

On Mon Aug 16 14:26:38 2004, Aki Niemi wrote:
> > Creating new URI schemes isn't really the answer, I think - we 
> need > some other additional, backwards compatible, method for 
> indicating > it's XCAP (Or WebDAV, or any of the 37,576 protocols 
> now built on top > of HTTP). For XCAP, document fragment 
> identifiers would work, given > that they're not used for XCAP. In 
> general, an illegal fragment > identifier might be best - #? for 
> instance. I've no idea what current > applications might do with a 
> double fragment identifier, though.
> 
Emphasis on "supposed to be".

The nice thing about fragment identifiers is that they're not sent to 
the HTTP server, so they'd remain backwards compatible. The nasty 
thing is that it's an unashamed hack.

FWIW, those clients I've tested ignore a double-fragment, so it's a 
technically feasable hack with few ill-effects.

> user experience. Not by far, but still...
I agree, but:

a) A useful property of protocols based on HTTP is that they behave 
like HTTP, because they are. Pretend, for a moment, that XCAP could 
be used to handle configuration such as bookmarks. [I'm not yet 
convinced it's suitable, but it makes for a nice example.]

It'd be possible, and quite fun, to have an XCAP URI (Or rather, 
'http' scheme URI to an XCAP server), which returned the XML fragment 
containing bookmark data, with a stylesheet PI directing a typical 
web browser to render the XML fragment as a web page with links, as 
in a typical "links" page.

b) By the time you've got the MIME type, that's also too late to do 
anything useful with an XCAP server, since the more useful property 
for dispatching is the URI, not the data you get back. Therefore a 
dispatch must operate on the URI rather than the MIME type returned.

Whatever the case, I do think that this problem does exist, and is 
also outside the scope of this WG. It's purely a problem created by 
the heavy overloading that HTTP has received.

Dave.