Re: Fwd: I-D Action:draft-roach-sip-http-subscribe-00.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
I have some questions about this proposal, that might be due to my
lack of understanding of the context. I am not sure if you intended
questions to be raised on this group, so please point in the right
direction if it's the wrong place:
Is the intent of this mechanism to have each resource's monitor URI be
different. That, is if I have two separate URIs/resources, can they
both share the same subscription/monitor URI, such that a client can
connect to that same URI to track changes to both resources? If so,
are there any proposed mechanism for how the subscriber declares to
the subscription server which resources it wishes to monitor? Is this
left up to the protocols used by the subscription servers? I would
like to look at using this mechanism from our JavaScript library using
"Comet"-style connections (long-lived connections to a server over
HTTP awaiting an asynchronous response from the server with
notifications), but within browser, connections are limited and one
would need to be able to use a single connection for all subscriptions
(for a given server). Also, it seems a prime target transport for this
type of subscription mechanism would be with the WebSocket protocol
that (the ID for that was recently distributed). It certainly seems
that message/httpfrag messages could be delivered nicely with WebSockets.

Also, I was curious if this approach leaves open the possibility that
resource changes could be "missed" between the time that a
client/subscriber receives a response from the server with a monitor
link and the time it is able to connect to the monitor resource for
tracking changes? Is there any way to ensure that all changes are
received, even in this window. We have worked on an HTTP-semantics
based notification system, and we included the subscription request
within the HTTP request so that the subscription and the HTTP response
would leave no window for missing notifications.

Thanks,
Kris


Mark Nottingham wrote:
> FYI; I've been discussing it a bit with them over on the bliss list.
>
>
> Begin forwarded message:
>
>> From: Internet-Drafts@ietf.org
>> Date: 21 November 2008 8:15:01 AM
>> To: i-d-announce@ietf.org
>> Subject: I-D Action:draft-roach-sip-http-subscribe-00.txt
>> Reply-To: internet-drafts@ietf.org
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>     Title           : A SIP Event Package for Subscribing to
>> Changes to an HTTP Resource
>>     Author(s)       : A. Roach
>>     Filename        : draft-roach-sip-http-subscribe-00.txt
>>     Pages           : 12
>>     Date            : 2008-11-20
>>
>> The Session Initiation Protocol (SIP) is increasingly being used in
>> systems that are tightly coupled with Hypertext Transport Protocol
>> (HTTP) servers for a variety of reasons.  In many of these cases,
>> applications can benefit from being able to discover, in near-real-
>> time, when a specific HTTP resource is created, changed, or deleted.
>> This document proposes a mechanism, based on the SIP events
>> framework, for doing so.
>>
>> This document further proposes that the HTTP work necessary to make
>> such a mechanism work be extensible to support protocols other than
>> SIP for monitoring HTTP resources.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-roach-sip-http-subscribe-00.txt
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>

- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iEYEARECAAYFAkln1mEACgkQ9VpNnHc4zAw1BACdF1hRRS8SMvdWVkAJ0VO84tez
gWIAniSAs+KPG1xYZcy/gRrpkdBkW1cj
=CMbo
-----END PGP SIGNATURE-----

Received on Friday, 9 January 2009 22:58:28 UTC