From bliss-bounces@ietf.org Thu Jan 1 21:25:01 2009 Return-Path: X-Original-To: bliss-archive@optimus.ietf.org Delivered-To: ietfarch-bliss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BAC928C1A4; Thu, 1 Jan 2009 21:25:01 -0800 (PST) X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCAE028C15F for ; Thu, 1 Jan 2009 20:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgSu0SLcCbIF for ; Thu, 1 Jan 2009 20:52:28 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 7A16028C194 for ; Thu, 1 Jan 2009 20:52:28 -0800 (PST) Received: from [192.168.2.103] (unknown [71.179.34.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 06744D05A0; Thu, 1 Jan 2009 23:52:11 -0500 (EST) Message-Id: <115660BB-5C4F-4F94-BC45-D8358EE3474D@mnot.net> From: Mark Nottingham To: Adam Roach In-Reply-To: <4942FCF5.1090509@nostrum.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 1 Jan 2009 23:52:10 -0500 References: <4925F054.5020205@nostrum.com> <167dfb9b0811201703i3162dbbbpabfc085ccef6754b@mail.gmail.com> <4926351B.6000907@nostrum.com> <167dfb9b0811210007q46e938b3y9d1f9589b271bed6@mail.gmail.com> <4926D995.2010508@nostrum.com> <4D3036ED-3CDC-4FEE-ABB1-AE2D341AA3FC@mnot.net> <4942FCF5.1090509@nostrum.com> X-Mailer: Apple Mail (2.929.2) X-Mailman-Approved-At: Thu, 01 Jan 2009 21:24:59 -0800 Cc: bliss@ietf.org, Theo Zourzouvillys Subject: Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http-subscribe-00.txt] X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1188049551==" Sender: bliss-bounces@ietf.org Errors-To: bliss-bounces@ietf.org --===============1188049551== Content-Type: multipart/alternative; boundary=Apple-Mail-3--838339624 --Apple-Mail-3--838339624 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Adam, Sorry for the holiday-induced delay. On 13/12/2008, at 11:08 AM, Adam Roach wrote: > >> * Following on that thought, the idea behind the most recent Link >> draft is to talk about link relations generically, and make Link >> headers one use of them. > > I understand what you're saying, but I'm somewhat sensitive to > having many optional ways of doing the same thing in the same > protocol. In my experience, you either end up with everyone > supporting every way of doing things (driving up implementation > costs), or with people selecting only their favorite mechanisms > (driving down interoperability). There is, of course, an unhappy > medium between those two extremes, in which you get both an increase > in implementation complexity and a decrease in interoperability > (albeit to a lesser degree). I agree, and wasn't proposing that multiple discovery mechanisms be called out (I see others drafts doing this and wince too); rather, just that the door be left open for other ways to be used if someone wants build on top of this in the future. >> * 3.4 Subscription Duration -- just a thought, is it worth tying >> the default subscription duration to the freshness lifetime of the >> HTTP response (as defined by HTTP)? > > I'm not sure. The goal behind selecting subscription durations is to > balance server load against time to recover in the case of a > failure. If you want to propose a concrete formula, I'll be happy to > incorporate it into the document, but I think it is of limited value. I'm not sure enough of it to make a concrete proposal. I can definitely see situations where the subscription lifetime varies significantly, just wondering if it's better to use the expiry time as a default, instead of baking in a (fairly arbitrary) number. >> * 3.5.1 message/httpfrag -- did you consider using application/http >> (defined in RFC2616)? I mention this because HTTP already defines >> how to update a cache entry's headers based upon a HEAD or 304 >> response; it would be nice to reuse that if possible. Also, what >> does making the status-line optional bring? The semantics of the >> message would be clearer if it were required... > > I'm hardly an HTTP expert -- so, on first glance, I feared that re- > using message/http would run afoul of semantic restrictions > associated with that content type (in the same way that omitting > critical header fields from a SIP message would make it invalid; > that is what drove development of the message/sipfrag content type). > > If you think that re-use of message/http is kosher in this context, > then I'd be quite pleased to use that instead of defining a new > content-type. I strongly prefer re-use over re-invention. > > The optional status-line feature was copied from message/sipfrag. It > has little value here, so I'm happy to make status lines mandatory. Not message/http, application/http; > The application/http type can be used to enclose a pipeline of one > or more HTTP request or response messages (not intermixed). I think this will work, provided that the status-line is mandatory. Remember that a HEAD response is allowed to omit a body, so from the purely syntactic standpoint, you should be OK if the body is missing. However, see below. >> * 3.5.2 - Why require an ETag or Content-MD5? Why recommend a Last- >> Modified? > > Philosophically: SIP Events, in general, reports the state of a > resource, not events that change its state (despite its name, which > I have grown to regret). It is true that state is usefully reported > when it changes, but thinking about it as the changes themselves > instead of the resultant state tends to put the cart before the horse. > > Practically: without some means of tying the notification to the > resultant HTTP document, you end up with race conditions in which > the state of a document changes between retrieval and subscription > to its state. There are other ways to solve this race, but they're > messy. OK, that makes sense. Would you be comfortable making these requirements a SHOULD (if they aren't already)? > [from a later message] > >> * Does the NOTIFY message include the URI of the resource that has >> changed (didn't see it, but I may be missing something). It should >> be added if not; otherwise, you're baking in a one-to-one >> relationship between monitoring channels and http URIs. There will >> be use cases where the receiver of the NOTIFY doesn't have enough >> context to associate the message body you're sending with a URI. > > Good point. How would you feel about adding a requirement to include > a "Link" header in the message/http body with a relation type of > "self"? Content-Location is probably more appropriate. >> * The simplest and most efficient notification message to send is >> "this resource has changed"; the client can then decide whether or >> not to fetch an update, and combining any old response with a new >> one is simple. It also assures that the subscribing client isn't >> required to implement a cache. I would very much encourage you to >> support this mode of interaction. > > That is effectively what I'm trying to do; however, see my notes > above about race conditions. If a client doesn't want to cache > anything, they can simply treat each NOTIFY message as an indication > that the resource has (likely) changed. (They would still be well > off keeping track of the Content-MD5 and/or ETag for the brief > period between the HTTP operation and the SIP subscription just to > make sure the resource didn't change between those steps). OK. My concern is when the client does have a cached or otherwise locally stored copy, and they need to combine it with a partial response -- e.g., when the status code isn't present, or partial headers are there, etc. This area is reasonably well-defined when used inside of HTTP, but taken out of context, it doesn't hold up terribly well. >> * Conversely, if you are you intent on allowing transfer of an >> entity with a notification, you may want to consider allowing the >> transfer of multiple entities, to allow the use of content >> negotiation (e.g., both an English and French representation under >> the same URI, or a png and a gif). application/http would support >> this. > > I'm ambivalent about allowing the inclusion of bodies in the > notifications. I would hesitate precluding future specifications > from doing so, but I'm not all that interested in developing a > complicated mechanism in this document that replicates the full set > of HTTP features (such as language and content negotiation). I see. I didn't get that from reading the spec; my concerns were about the more complex cases where people were trying to update headers and bodies using the notifications (as above). Perhaps the right thing to do is to have a very limited new media type that communicates just a few things; * URI (required) * Content-MD5 (optional) * ETag (optional) * Last-Modified (optional) without the option for status-line, other headers or body, to avoid the complexity. More advanced uses could use application/http (but you wouldn't necessarily need to specify how to do this...) Conneg definitely makes things more complex. I think that it's legitimate to say that a notification applies to all representations of a resource, and that you can't selectively send notifications for a particular representation. The only sticky part here is that if there *are* multiple representations for a resource, it's important for the server to keep which one it's using for the ETag and/or Content-MD5 straight. > [responses to previous messages in thread] > >> ... >> That said, I agree that the draft shouldn't preclude other >> discovery mechanisms, as mentioned above. > > I'll reiterate my concerns about too many ways to do something. I'm > adding in the and mechanisms, but I'd hate to > see an explosion of mechanisms here, as it would make client > implementations untenably complicated. Yes; see above. Cheers, -- Mark Nottingham http://www.mnot.net/ --Apple-Mail-3--838339624 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Hi = Adam,

Sorry for the holiday-induced = delay.

On 13/12/2008, at 11:08 AM, Adam Roach = wrote:

*= Following on that thought, the idea behind the most recent Link draft = is to talk about link relations generically, and make Link headers one = use of them.

I understand what you're saying, but = I'm somewhat sensitive to having many optional ways of doing the same = thing in the same protocol. In my experience, you either end up with = everyone supporting every way of doing things (driving up implementation = costs), or with people selecting only their favorite mechanisms (driving = down interoperability). There is, of course, an unhappy medium between = those two extremes, in which you get both an increase in implementation = complexity and a decrease in interoperability (albeit to a lesser = degree).

I agree, and wasn't = proposing that multiple discovery mechanisms be called out (I see others = drafts doing this and wince too); rather, just that the door be left = open for other ways to be used if someone wants build on top of this in = the future.


* = 3.4 Subscription Duration -- just a thought, is it worth tying the = default subscription duration to the freshness lifetime of the HTTP = response (as defined by HTTP)?

I'm not sure. The = goal behind selecting subscription durations is to balance server load = against time to recover in the case of a failure. If you want to propose = a concrete formula, I'll be happy to incorporate it into the document, = but I think it is of limited = value.

I'm not sure enough of it = to make a concrete proposal. I can definitely see situations where the = subscription lifetime varies significantly, just wondering if it's = better to use the expiry time as a default, instead of baking in a = (fairly arbitrary) number.


* 3.5.1 message/httpfrag -- = did you consider using application/http (defined in RFC2616)? I mention = this because HTTP already defines how to update a cache entry's headers = based upon a HEAD or 304 response; it would be nice to reuse that if = possible. Also, what does making the status-line optional bring? The = semantics of the message would be clearer if it were = required...

I'm hardly an HTTP expert -- so, on = first glance, I feared that re-using message/http would run afoul of = semantic restrictions associated with that content type (in the same way = that omitting critical header fields from a SIP message would make it = invalid; that is what drove development of the message/sipfrag content = type).

If you think that re-use of message/http is kosher in this = context, then I'd be quite pleased to use that instead of defining a new = content-type. I strongly prefer re-use over re-invention.

The = optional status-line feature was copied from message/sipfrag. It has = little value here, so I'm happy to make status lines = mandatory.

Not message/http, = application/http;
The application/http type can be used to enclose a
   pipeline of one or more HTTP request or response messages (not
   intermixed).
I think this = will work, provided that the status-line is mandatory. Remember that a = HEAD response is allowed to omit a body, so from the purely syntactic = standpoint, you should be OK if the body is missing. However, see = below.


* 3.5.2 - Why require an ETag or Content-MD5? Why = recommend a Last-Modified?

Philosophically: SIP = Events, in general, reports the state of a resource, not events that = change its state (despite its name, which I have grown to regret). It is = true that state is usefully reported when it changes, but thinking about = it as the changes themselves instead of the resultant state tends to put = the cart before the horse.

Practically: without some means of = tying the notification to the resultant HTTP document, you end up with = race conditions in which the state of a document changes between = retrieval and subscription to its state. There are other ways to solve = this race, but they're messy.

OK, that = makes sense. Would you be comfortable making these requirements a SHOULD = (if they aren't already)?


[from a later message]

* Does the NOTIFY message include the URI of the resource = that has changed (didn't see it, but I may be missing something). It = should be added if not; otherwise, you're baking in a one-to-one = relationship between monitoring channels and http URIs. There will be = use cases where the receiver of the NOTIFY doesn't have enough context = to associate the message body you're sending with a = URI.

Good point. How would you feel about adding a = requirement to include a "Link" header in the message/http body with a = relation type of = "self"?

Content-Location is = probably more appropriate.


* The simplest and most = efficient notification message to send is "this resource has changed"; = the client can then decide whether or not to fetch an update, and = combining any old response with a new one is simple. It also assures = that the subscribing client isn't required to implement a cache. I would = very much encourage you to support this mode of = interaction.

That is effectively what I'm trying to = do; however, see my notes above about race conditions. If a client = doesn't want to cache anything, they can simply treat each NOTIFY = message as an indication that the resource has (likely) changed. (They = would still be well off keeping track of the Content-MD5 and/or ETag for = the brief period between the HTTP operation and the SIP subscription = just to make sure the resource didn't change between those = steps).

OK. My concern is when the = client does have a cached or otherwise locally stored copy, and they = need to combine it with a partial response -- e.g., when the status code = isn't present, or partial headers are there, etc. This area is = reasonably well-defined when used inside of HTTP, but taken out of = context, it doesn't hold up terribly = well. 


* Conversely, if you are = you intent on allowing transfer of an entity with a notification, you = may want to consider allowing the transfer of multiple entities, to = allow the use of content negotiation (e.g., both an English and French = representation under the same URI, or a png and a gif). application/http = would support this.

I'm ambivalent about allowing = the inclusion of bodies in the notifications. I would hesitate = precluding future specifications from doing so, but I'm not all that = interested in developing a complicated mechanism in this document that = replicates the full set of HTTP features (such as language and content = negotiation).

I see. I didn't get = that from reading the spec; my concerns were about the more complex = cases where people were trying to update headers and bodies using the = notifications (as above). 

Perhaps the = right thing to do is to have a very limited new media type that = communicates just a few things;
 * URI = (required)
 * Content-MD5 (optional)
 * = ETag (optional)
 * Last-Modified = (optional)

without the option for status-line, = other headers or body, to avoid the complexity. More advanced uses could = use application/http (but you wouldn't necessarily need to specify how = to do this...)

Conneg definitely makes things = more complex. I think that it's legitimate to say that a notification = applies to all representations of a resource, and that you can't = selectively send notifications for a particular representation. The only = sticky part here is that if there *are* multiple representations for a = resource, it's important for the server to keep which one it's using for = the ETag and/or Content-MD5 = straight. 


[responses to previous messages in = thread]

...
That said, I agree that the draft shouldn't preclude other = discovery mechanisms, as mentioned above.

I'll = reiterate my concerns about too many ways to do something. I'm adding in = the <link> and <atom:link/> mechanisms, but I'd hate to see an = explosion of mechanisms here, as it would make client implementations = untenably complicated.

Yes; see = above.

Cheers,
=

--
Mark Nottingham     http://www.mnot.net/
=

= --Apple-Mail-3--838339624-- --===============1188049551== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss --===============1188049551==-- From bliss-bounces@ietf.org Tue Jan 6 05:32:48 2009 Return-Path: X-Original-To: bliss-archive@optimus.ietf.org Delivered-To: ietfarch-bliss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325A73A6783; Tue, 6 Jan 2009 05:32:48 -0800 (PST) X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98B73A6783 for ; Tue, 6 Jan 2009 05:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YW-CdS43WQgc for ; Tue, 6 Jan 2009 05:32:46 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id E35A53A6768 for ; Tue, 6 Jan 2009 05:32:45 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KD100M86XM6X0@siemenscomms.co.uk> for bliss@ietf.org; Tue, 06 Jan 2009 13:32:30 +0000 (GMT) Date: Tue, 06 Jan 2009 13:32:28 +0000 From: "Elwell, John" To: bliss@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00167DA79@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: draft-ietf-bliss-ach-analysis-04 available Thread-Index: AclwAzhYAHCj2gfpRKC+JmOdOwg/Ag== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [BLISS] draft-ietf-bliss-ach-analysis-04 available X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: bliss-bounces@ietf.org Errors-To: bliss-bounces@ietf.org In accordance with agreements at IETF 73 and the subsequent consensus call on the list, I have updated the draft as follows: - targeted at BCP rather than informational; - added new section 6 "Best Practices for ACH" containing normative statements, e.g., including use of response codes; - deleted open issue associated with 480 response code for explicit rejection / local; - added placeholder for referencing a to-be-written framework draft on REST (Jonathan Rosenberg / Keith Griffin) - added placeholder for defining URL structures for ACH configuration (forwarding, DND, etc.) and giving examples (in place of existing material); - left placeholder for referencing a generic event package for notifications of resource changes (draft-roach-sip-http-subscribe seems to be a candidate); - various editorial tidy-ups. The draft is available at: http://tools.ietf.org/id/draft-ietf-bliss-ach-analysis-03.txt In my opinion, this draft can now be put on hold awaiting progress on the REST framework and event package work items. John _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jan 6 05:45:02 2009 Return-Path: X-Original-To: bliss-archive@optimus.ietf.org Delivered-To: ietfarch-bliss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BCA23A6970; Tue, 6 Jan 2009 05:45:02 -0800 (PST) X-Original-To: bliss@ietf.org Delivered-To: bliss@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 438BB3A6783; Tue, 6 Jan 2009 05:45:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090106134501.438BB3A6783@core3.amsl.com> Date: Tue, 6 Jan 2009 05:45:01 -0800 (PST) Cc: bliss@ietf.org Subject: [BLISS] I-D Action:draft-ietf-bliss-ach-analysis-04.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: bliss-bounces@ietf.org Errors-To: bliss-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF. Title : An Analysis of Automatic Call Handling Implementation Issues in the Session Initiation Protocol (SIP) Author(s) : J. Elwell Filename : draft-ietf-bliss-ach-analysis-04.txt Pages : 19 Date : 2009-01-06 This discusses problems associated with automatic call handling (ACH) when using the Session Initiation Protocol (SIP) and specifies some best practices to help achieve interoperability. This work is being discussed on the bliss@ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bliss-ach-analysis-04.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-bliss-ach-analysis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-06053010.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss --NextPart-- From bliss-bounces@ietf.org Tue Jan 6 06:09:34 2009 Return-Path: X-Original-To: bliss-archive@optimus.ietf.org Delivered-To: ietfarch-bliss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D83463A69DE; Tue, 6 Jan 2009 06:09:34 -0800 (PST) X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4B83A699E for ; Tue, 6 Jan 2009 06:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03NSeq1+zhFW for ; Tue, 6 Jan 2009 06:09:32 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id B2B993A6997 for ; Tue, 6 Jan 2009 06:09:32 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KD10015XZBJXX@siemenscomms.co.uk> for bliss@ietf.org; Tue, 06 Jan 2009 14:09:19 +0000 (GMT) Date: Tue, 06 Jan 2009 14:09:17 +0000 From: "Elwell, John" To: bliss@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00167DAE8@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: draft-ietf-bliss-ach-analysis-04 available Thread-Index: AclwAzhYAHCj2gfpRKC+JmOdOwg/Ag== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [BLISS] draft-ietf-bliss-ach-analysis-04 available X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: bliss-bounces@ietf.org Errors-To: bliss-bounces@ietf.org I am reposting this because somehow the tracker gave me the wrong URL before (03 instead of 04)! The correct URL is below. ----------------- In accordance with agreements at IETF 73 and the subsequent consensus call on the list, I have updated the draft as follows: - targeted at BCP rather than informational; - added new section 6 "Best Practices for ACH" containing normative statements, e.g., including use of response codes; - deleted open issue associated with 480 response code for explicit rejection / local; - added placeholder for referencing a to-be-written framework draft on REST (Jonathan Rosenberg / Keith Griffin) - added placeholder for defining URL structures for ACH configuration (forwarding, DND, etc.) and giving examples (in place of existing material); - left placeholder for referencing a generic event package for notifications of resource changes (draft-roach-sip-http-subscribe seems to be a candidate); - various editorial tidy-ups. The draft is available at: http://tools.ietf.org/id/draft-ietf-bliss-ach-analysis-04.txt In my opinion, this draft can now be put on hold awaiting progress on the REST framework and event package work items. John _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 7 09:12:02 2009 Return-Path: X-Original-To: bliss-archive@optimus.ietf.org Delivered-To: ietfarch-bliss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0127B3A680A; Wed, 7 Jan 2009 09:12:02 -0800 (PST) X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FC123A680A for ; Wed, 7 Jan 2009 09:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGipHZ+LHp-B for ; Wed, 7 Jan 2009 09:11:59 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 01EC03A6802 for ; Wed, 7 Jan 2009 09:11:58 -0800 (PST) Received: from dn3-231.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n07HBfeU057896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 11:11:41 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4964E24C.6040204@nostrum.com> Date: Wed, 07 Jan 2009 11:11:40 -0600 From: Adam Roach User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Mark Nottingham References: <4925F054.5020205@nostrum.com> <167dfb9b0811201703i3162dbbbpabfc085ccef6754b@mail.gmail.com> <4926351B.6000907@nostrum.com> <167dfb9b0811210007q46e938b3y9d1f9589b271bed6@mail.gmail.com> <4926D995.2010508@nostrum.com> <4D3036ED-3CDC-4FEE-ABB1-AE2D341AA3FC@mnot.net> <4942FCF5.1090509@nostrum.com> <115660BB-5C4F-4F94-BC45-D8358EE3474D@mnot.net> In-Reply-To: <115660BB-5C4F-4F94-BC45-D8358EE3474D@mnot.net> Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/8842/Wed Jan 7 08:06:50 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: bliss@ietf.org, Theo Zourzouvillys Subject: Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http-subscribe-00.txt] X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: bliss-bounces@ietf.org Errors-To: bliss-bounces@ietf.org Mark: I'm working on the next draft for this document, which I hope will address the points you and Theo have raised so far. I'm still not completely comfortable that I understand the body-type concerns -- some qustions below. On 1/1/09 10:52 PM, Mark Nottingham wrote: > > On 13/12/2008, at 11:08 AM, Adam Roach wrote: >>> * 3.5.1 message/httpfrag -- did you consider using application/http >>> (defined in RFC2616)? I mention this because HTTP already defines >>> how to update a cache entry's headers based upon a HEAD or 304 >>> response; it would be nice to reuse that if possible. Also, what >>> does making the status-line optional bring? The semantics of the >>> message would be clearer if it were required... >> >> I'm hardly an HTTP expert -- so, on first glance, I feared that >> re-using message/http would run afoul of semantic restrictions >> associated with that content type (in the same way that omitting >> critical header fields from a SIP message would make it invalid; that >> is what drove development of the message/sipfrag content type). >> >> If you think that re-use of message/http is kosher in this context, >> then I'd be quite pleased to use that instead of defining a new >> content-type. I strongly prefer re-use over re-invention. >> >> The optional status-line feature was copied from message/sipfrag. It >> has little value here, so I'm happy to make status lines mandatory. > > Not message/http, application/http; >> The application/http type can be used to enclose a pipeline of one or >> more HTTP request or response messages (not intermixed). > I think this will work, provided that the status-line is mandatory. > Remember that a HEAD response is allowed to omit a body, so from the > purely syntactic standpoint, you should be OK if the body is missing. > However, see below. I think I understand what you're saying here, but I have one remaining point of confusion: why would I use application/http over message/http? As things are currently defined, we won't have more than one HTTP response conveyed in a single MIME part at a time. ... > OK. My concern is when the client does have a cached or otherwise > locally stored copy, and they need to combine it with a partial > response -- e.g., when the status code isn't present, or partial > headers are there, etc. This area is reasonably well-defined when used > inside of HTTP, but taken out of context, it doesn't hold up terribly > well. I'm happy to specify that the body of the NOTIFY is a full set of HTTP headers, if that satisfies your concern. ... > without the option for status-line, other headers or body, to avoid > the complexity. More advanced uses could use application/http (but you > wouldn't necessarily need to specify how to do this...) I'd like to avoid defining a new syntax. In particular, I'd like to be able to re-use standard HTTP parsers for the body, and we risk losing that if we start crafting our own syntax definition. /a _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Jan 9 13:26:32 2009 Return-Path: X-Original-To: bliss-archive@optimus.ietf.org Delivered-To: ietfarch-bliss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5DA3A6936; Fri, 9 Jan 2009 13:26:32 -0800 (PST) X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 198423A6936 for ; Fri, 9 Jan 2009 13:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pbr3JBf7lWqp for ; Fri, 9 Jan 2009 13:26:30 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 10CED3A67EE for ; Fri, 9 Jan 2009 13:26:29 -0800 (PST) Received: from dn3-231.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n09LQD5r034957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 15:26:14 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4967C0F5.6000709@nostrum.com> Date: Fri, 09 Jan 2009 15:26:13 -0600 From: Adam Roach User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Mark Nottingham References: <4925F054.5020205@nostrum.com> <167dfb9b0811201703i3162dbbbpabfc085ccef6754b@mail.gmail.com> <4926351B.6000907@nostrum.com> <167dfb9b0811210007q46e938b3y9d1f9589b271bed6@mail.gmail.com> <4926D995.2010508@nostrum.com> <4D3036ED-3CDC-4FEE-ABB1-AE2D341AA3FC@mnot.net> <4942FCF5.1090509@nostrum.com> <115660BB-5C4F-4F94-BC45-D8358EE3474D@mnot.net> In-Reply-To: <115660BB-5C4F-4F94-BC45-D8358EE3474D@mnot.net> Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/8848/Fri Jan 9 07:16:38 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: bliss@ietf.org, Theo Zourzouvillys Subject: Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http-subscribe-00.txt] X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: bliss-bounces@ietf.org Errors-To: bliss-bounces@ietf.org I propose that we move further discussion of this to the SIP mailing list. /a On 1/1/09 10:52 PM, Mark Nottingham wrote: > Hi Adam, > > Sorry for the holiday-induced delay. > > On 13/12/2008, at 11:08 AM, Adam Roach wrote: >> >>> * Following on that thought, the idea behind the most recent Link >>> draft is to talk about link relations generically, and make Link >>> headers one use of them. >> >> I understand what you're saying, but I'm somewhat sensitive to having >> many optional ways of doing the same thing in the same protocol. In >> my experience, you either end up with everyone supporting every way >> of doing things (driving up implementation costs), or with people >> selecting only their favorite mechanisms (driving down >> interoperability). There is, of course, an unhappy medium between >> those two extremes, in which you get both an increase in >> implementation complexity and a decrease in interoperability (albeit >> to a lesser degree). > > I agree, and wasn't proposing that multiple discovery mechanisms be > called out (I see others drafts doing this and wince too); rather, > just that the door be left open for other ways to be used if someone > wants build on top of this in the future. > > >>> * 3.4 Subscription Duration -- just a thought, is it worth tying the >>> default subscription duration to the freshness lifetime of the HTTP >>> response (as defined by HTTP)? >> >> I'm not sure. The goal behind selecting subscription durations is to >> balance server load against time to recover in the case of a failure. >> If you want to propose a concrete formula, I'll be happy to >> incorporate it into the document, but I think it is of limited value. > > I'm not sure enough of it to make a concrete proposal. I can > definitely see situations where the subscription lifetime varies > significantly, just wondering if it's better to use the expiry time as > a default, instead of baking in a (fairly arbitrary) number. > > >>> * 3.5.1 message/httpfrag -- did you consider using application/http >>> (defined in RFC2616)? I mention this because HTTP already defines >>> how to update a cache entry's headers based upon a HEAD or 304 >>> response; it would be nice to reuse that if possible. Also, what >>> does making the status-line optional bring? The semantics of the >>> message would be clearer if it were required... >> >> I'm hardly an HTTP expert -- so, on first glance, I feared that >> re-using message/http would run afoul of semantic restrictions >> associated with that content type (in the same way that omitting >> critical header fields from a SIP message would make it invalid; that >> is what drove development of the message/sipfrag content type). >> >> If you think that re-use of message/http is kosher in this context, >> then I'd be quite pleased to use that instead of defining a new >> content-type. I strongly prefer re-use over re-invention. >> >> The optional status-line feature was copied from message/sipfrag. It >> has little value here, so I'm happy to make status lines mandatory. > > Not message/http, application/http; >> The application/http type can be used to enclose a pipeline of one or >> more HTTP request or response messages (not intermixed). > I think this will work, provided that the status-line is mandatory. > Remember that a HEAD response is allowed to omit a body, so from the > purely syntactic standpoint, you should be OK if the body is missing. > However, see below. > > >>> * 3.5.2 - Why require an ETag or Content-MD5? Why recommend a >>> Last-Modified? >> >> Philosophically: SIP Events, in general, reports the state of a >> resource, not events that change its state (despite its name, which I >> have grown to regret). It is true that state is usefully reported >> when it changes, but thinking about it as the changes themselves >> instead of the resultant state tends to put the cart before the horse. >> >> Practically: without some means of tying the notification to the >> resultant HTTP document, you end up with race conditions in which the >> state of a document changes between retrieval and subscription to its >> state. There are other ways to solve this race, but they're messy. > > OK, that makes sense. Would you be comfortable making these > requirements a SHOULD (if they aren't already)? > > >> [from a later message] >> >>> * Does the NOTIFY message include the URI of the resource that has >>> changed (didn't see it, but I may be missing something). It should >>> be added if not; otherwise, you're baking in a one-to-one >>> relationship between monitoring channels and http URIs. There will >>> be use cases where the receiver of the NOTIFY doesn't have enough >>> context to associate the message body you're sending with a URI. >> >> Good point. How would you feel about adding a requirement to include >> a "Link" header in the message/http body with a relation type of "self"? > > Content-Location is probably more appropriate. > > >>> * The simplest and most efficient notification message to send is >>> "this resource has changed"; the client can then decide whether or >>> not to fetch an update, and combining any old response with a new >>> one is simple. It also assures that the subscribing client isn't >>> required to implement a cache. I would very much encourage you to >>> support this mode of interaction. >> >> That is effectively what I'm trying to do; however, see my notes >> above about race conditions. If a client doesn't want to cache >> anything, they can simply treat each NOTIFY message as an indication >> that the resource has (likely) changed. (They would still be well off >> keeping track of the Content-MD5 and/or ETag for the brief period >> between the HTTP operation and the SIP subscription just to make sure >> the resource didn't change between those steps). > > OK. My concern is when the client does have a cached or otherwise > locally stored copy, and they need to combine it with a partial > response -- e.g., when the status code isn't present, or partial > headers are there, etc. This area is reasonably well-defined when used > inside of HTTP, but taken out of context, it doesn't hold up terribly > well. > > >>> * Conversely, if you are you intent on allowing transfer of an >>> entity with a notification, you may want to consider allowing the >>> transfer of multiple entities, to allow the use of content >>> negotiation (e.g., both an English and French representation under >>> the same URI, or a png and a gif). application/http would support this. >> >> I'm ambivalent about allowing the inclusion of bodies in the >> notifications. I would hesitate precluding future specifications from >> doing so, but I'm not all that interested in developing a complicated >> mechanism in this document that replicates the full set of HTTP >> features (such as language and content negotiation). > > I see. I didn't get that from reading the spec; my concerns were about > the more complex cases where people were trying to update headers and > bodies using the notifications (as above). > > Perhaps the right thing to do is to have a very limited new media type > that communicates just a few things; > * URI (required) > * Content-MD5 (optional) > * ETag (optional) > * Last-Modified (optional) > > without the option for status-line, other headers or body, to avoid > the complexity. More advanced uses could use application/http (but you > wouldn't necessarily need to specify how to do this...) > > Conneg definitely makes things more complex. I think that it's > legitimate to say that a notification applies to all representations > of a resource, and that you can't selectively send notifications for a > particular representation. The only sticky part here is that if there > *are* multiple representations for a resource, it's important for the > server to keep which one it's using for the ETag and/or Content-MD5 > straight. > > >> [responses to previous messages in thread] >> >>> ... >>> That said, I agree that the draft shouldn't preclude other discovery >>> mechanisms, as mentioned above. >> >> I'll reiterate my concerns about too many ways to do something. I'm >> adding in the and mechanisms, but I'd hate to see >> an explosion of mechanisms here, as it would make client >> implementations untenably complicated. > > Yes; see above. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jan 19 11:27:55 2009 Return-Path: X-Original-To: bliss-archive@optimus.ietf.org Delivered-To: ietfarch-bliss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEDDE3A6827; Mon, 19 Jan 2009 11:27:54 -0800 (PST) X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1892A3A67E2 for ; Mon, 19 Jan 2009 11:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAp73Za+kFPN for ; Mon, 19 Jan 2009 11:27:53 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id F310F3A6827 for ; Mon, 19 Jan 2009 11:27:52 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0JJR9QV032373 for ; Mon, 19 Jan 2009 21:27:34 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 21:27:03 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 21:26:59 +0200 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 19 Jan 2009 20:26:58 +0100 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.107]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Mon, 19 Jan 2009 20:26:58 +0100 From: To: Date: Mon, 19 Jan 2009 20:26:56 +0100 Thread-Topic: ACH configuration next steps? Thread-Index: AclwAzhYAHCj2gfpRKC+JmOdOwg/AgKZVTyA Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D00167DAE8@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00167DAE8@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2009 19:26:59.0182 (UTC) FILETIME=[E5C608E0:01C97A6B] X-Nokia-AV: Clean Subject: [BLISS] ACH configuration next steps? X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: bliss-bounces@ietf.org Errors-To: bliss-bounces@ietf.org Hi, I'd like to start discussion on ACH configuration so that we can produce something by IETF 74. By ACH configuration I mean a mechanism to enable setting things such as to which number/URI the proxy should forward the incoming call when the user is busy. I've studied the case a bit and it appears to be that a good starting point would be to use SIMPLE HTTP (call it REST if you like) mechanism to create, read, write and delete a ruleset that looks awfully lot like CPL. In fact, I think we should just take CPL as a starting point and perhaps just cut some unnecessary features out of it. The main things to figure out would be just where to locate the resource(s). There could be more than one of them if we want to enable things like multiple profiles. I assume each profile would have its own ruleset. And hey, why not borrow the URI structure from XCAP AUID, that would save us from re-inventing that wheel. We could also borrow the extensibility model from XCAP, i.e. using XML namespaces and discovering which of them are supported by the server. I believe this would be an approach where we could complete something in a reasonable time. Is there any reason why that approach would not work? I've also looked at other approaches, such as using REST by breaking the dataset into a bunch of resources. One resource could be for instance the target for call forwarding on busy. That approach would work easily for the basic use cases too, but I believe it has two major shortcomings: * It is hard to build rules that have multiple conditions (e.g. take UA response ("busy")and time-of-day into account. That requires some kind of a rule language, such as CPL, where you can combine and order conditions and actions. * The extensibility model is undefined. Markus _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jan 19 11:56:14 2009 Return-Path: X-Original-To: bliss-archive@optimus.ietf.org Delivered-To: ietfarch-bliss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB7F3A691E; Mon, 19 Jan 2009 11:56:14 -0800 (PST) X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483173A6944 for ; Mon, 19 Jan 2009 11:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, FS_REPLICA=0.994, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3s722qyfyvE for ; Mon, 19 Jan 2009 11:56:12 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id E74643A6874 for ; Mon, 19 Jan 2009 11:56:10 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0JJtnhx005865 for ; Mon, 19 Jan 2009 21:55:52 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 21:55:44 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 21:55:40 +0200 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.107]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 19 Jan 2009 20:55:39 +0100 From: To: Date: Mon, 19 Jan 2009 20:55:37 +0100 Thread-Topic: ACH configuration requirements: replicating GSM functionality Thread-Index: AclwAzhYAHCj2gfpRKC+JmOdOwg/AgKaK6Dg Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D00167DAE8@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00167DAE8@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2009 19:55:40.0169 (UTC) FILETIME=[E78FCF90:01C97A6F] X-Nokia-AV: Clean Subject: [BLISS] ACH configuration requirements: replicating GSM functionality X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: bliss-bounces@ietf.org Errors-To: bliss-bounces@ietf.org Hi, I've looked at ACH configuration requirements and would like to make sure one fundamental set of requirements is addressed. GSM is the most popular system for mobile telephony with about 3 billion users. So, it is a pretty massive installed base. Eventually that service is expected to be REPLACED by SIP based mobile VoIP. One important missing piece still is how to replace the call handling settings supported by GSM. This is probably going to be a mandatory feature for many deployments, as even if using such settings is not that popular, there is at least some amount of users who use some of them so it'd be hard to just drop them in a commercial deployment. So, here's a list of settings that virtually every GSM phone offers, hidden somewhere in the depths of the menus: * Call forwarding unconditional: either to voicemail or to any other number. * Call forwarding on busy: either to voicemail or to any other number. * Call forwarding on no answer: either to voicemail or to any other number. * Call forwarding when not registered: either to voicemail or to any other number. * Call forwarding when not reachable: either to voicemail or to any other number. (There's very little difference between the last two cases from user's point of view so it would be fine to combine them.) The requirement is that there has to be a way to configure these settings on the SIP proxy/B2BUA implementing ACH for the user. At minimum this means 5 (or 4 if we combine) attributes with value "voicemail" or any sip/tel URI, and one attribute that defines the sip/tel URI for voicemail. Then there are settings for call barring too: * Barring on all outgoing calls: on/off * Barring on all outgoing international calls: on/off * Barring on all outgoing calls when roaming except to own service provider: on/off * Barring on all incoming calls: on/off * Barring on all incoming calls when roaming: on/off (The exact meaning of "roaming" in case of SIP is probably undefined, and does not matter if charging is depending where you are attached to the network. However, in some services there might be a difference.) So, this would mean at minimum that we need to define a way to set 5 boolean attributes. I believe that whatever BLISS does for ACH configuration, these use cases must be solved in the very first baseline version of the solution. At minimum we could design an amazingly simple solution to just solve this case. But since this is the RAI area ;) and we do have other requirements (for instance the reqs draft talks about time-of-day or caller identity based rules), I'd suggest HTTP/REST + CPL as a starting point, as I wrote in another mail. If there is interest, I could write the GSM reqs in a proper brief Internet-Draft in a more verbose way with references to the corresponding GSM specs. And, as always, a note that 3GPP is too working in this problem space and it would be good to make some progress in BLISS to discourage them from developing their own specific solution. Regards, Markus _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jan 19 16:46:46 2009 Return-Path: X-Original-To: bliss-archive@optimus.ietf.org Delivered-To: ietfarch-bliss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9173A6A86; Mon, 19 Jan 2009 16:46:46 -0800 (PST) X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4233A6A3E for ; Mon, 19 Jan 2009 16:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.685 X-Spam-Level: X-Spam-Status: No, score=-0.685 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDgo5YmsPmxX for ; Mon, 19 Jan 2009 16:46:44 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by core3.amsl.com (Postfix) with ESMTP id D5C253A6AA8 for ; Mon, 19 Jan 2009 16:46:44 -0800 (PST) Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id 231FC14805B for ; Mon, 19 Jan 2009 16:46:29 -0800 (PST) Message-ID: <49751EE9.4040005@matthew.at> Date: Mon, 19 Jan 2009 16:46:33 -0800 From: Matthew Kaufman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: bliss@ietf.org Subject: [BLISS] SLA/BLA/MLA history X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: matthew@matthew.at List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: bliss-bounces@ietf.org Errors-To: bliss-bounces@ietf.org I'm looking into the various existing/former ways of handling {Shared,Bridged} {Call, Line} Appearance to try to figure out who supports what in existing software/firmware. Does anyone know of an existing compilation of which types of support exist? I know of "line-seize"/"call-info" style (documented by Broadsoft) and two variations of "dialog;sla" style (one of of them documented by draft-anil-sipping-bla), so far, but perhaps there's more? I also have some information about which are supported by which phones, but I'm sure my knowledge here is weak, because I can't even figure out 100% what the phone on my own desk supports. (A Polycom that I know does "line-seize"/"call-info" but claims in documentation to support draft-anil-sipping-bla-02) and I certainly don't know what other major vendors do/don't support. If such a compilation doesn't exist already, I'd gladly collect information anyone has and put it together somewhere public. In my case, I'm trying to write some software that is compatible with at least one of the previous schemes (preferably whatever was/is most popular), but it might also be useful as a reference for a future improved standard. Matthew Kaufman _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jan 19 16:56:09 2009 Return-Path: X-Original-To: bliss-archive@optimus.ietf.org Delivered-To: ietfarch-bliss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF31A3A6A83; Mon, 19 Jan 2009 16:56:09 -0800 (PST) X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77AD03A6A83 for ; Mon, 19 Jan 2009 16:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2Nq5wUD+3Vo for ; Mon, 19 Jan 2009 16:56:07 -0800 (PST) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.205.23]) by core3.amsl.com (Postfix) with SMTP id 7B7403A6A24 for ; Mon, 19 Jan 2009 16:56:07 -0800 (PST) Received: (qmail 6580 invoked from network); 20 Jan 2009 01:15:25 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway03.websitewelcome.com with SMTP; 20 Jan 2009 01:15:25 -0000 Received: from fl1-125-197-201-242.tky.mesh.ad.jp ([125.197.201.242]:38922 helo=[10.0.1.2]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LP4u2-0003zm-4c; Mon, 19 Jan 2009 18:55:39 -0600 Message-Id: <6422E24B-C601-4B34-A2EE-65D961CE4E80@ntt-at.com> From: Shida Schubert To: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 20 Jan 2009 09:55:35 +0900 References: <0D5F89FAC29E2C41B98A6A762007F5D00167DAE8@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: bliss@ietf.org Subject: Re: [BLISS] ACH configuration next steps? X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: bliss-bounces@ietf.org Errors-To: bliss-bounces@ietf.org Hi Markus; As for this problem space and possible solution (simple HTTP), I have sent a reference to draft discussing REST along with the consensus of the WG from the last meeting to APP area for a review. I do think we should go ahead with the effort despite the outcome from the APP area review, and I think list of requirements that may benefit from the solution is welcome. Many Thanks Shida On 20-Jan-09, at 4:26 AM, wrote: > Hi, > > I'd like to start discussion on ACH configuration so that we can > produce something by IETF 74. By ACH configuration I mean a > mechanism to enable setting things such as to which number/URI the > proxy should forward the incoming call when the user is busy. > > I've studied the case a bit and it appears to be that a good > starting point would be to use SIMPLE HTTP (call it REST if you > like) mechanism to create, read, write and delete a ruleset that > looks awfully lot like CPL. In fact, I think we should just take CPL > as a starting point and perhaps just cut some unnecessary features > out of it. The main things to figure out would be just where to > locate the resource(s). There could be more than one of them if we > want to enable things like multiple profiles. I assume each profile > would have its own ruleset. And hey, why not borrow the URI > structure from XCAP AUID, that would save us from re-inventing that > wheel. We could also borrow the extensibility model from XCAP, i.e. > using XML namespaces and discovering which of them are supported by > the server. > > I believe this would be an approach where we could complete > something in a reasonable time. Is there any reason why that > approach would not work? > > I've also looked at other approaches, such as using REST by breaking > the dataset into a bunch of resources. One resource could be for > instance the target for call forwarding on busy. That approach would > work easily for the basic use cases too, but I believe it has two > major shortcomings: > * It is hard to build rules that have multiple conditions (e.g. > take UA response ("busy")and time-of-day into account. That requires > some kind of a rule language, such as CPL, where you can combine and > order conditions and actions. > * The extensibility model is undefined. > > Markus > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jan 19 16:58:37 2009 Return-Path: X-Original-To: bliss-archive@optimus.ietf.org Delivered-To: ietfarch-bliss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E7663A6AA5; Mon, 19 Jan 2009 16:58:37 -0800 (PST) X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAD043A6A24 for ; Mon, 19 Jan 2009 16:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cM-o9DwlZkB for ; Mon, 19 Jan 2009 16:58:35 -0800 (PST) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.22.93]) by core3.amsl.com (Postfix) with SMTP id 12E7F3A6A83 for ; Mon, 19 Jan 2009 16:58:35 -0800 (PST) Received: (qmail 22109 invoked from network); 20 Jan 2009 01:15:03 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway05.websitewelcome.com with SMTP; 20 Jan 2009 01:15:03 -0000 Received: from fl1-125-197-201-242.tky.mesh.ad.jp ([125.197.201.242]:38972 helo=[10.0.1.2]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LP4wX-0004RI-1r for bliss@ietf.org; Mon, 19 Jan 2009 18:58:13 -0600 Message-Id: <7B5E9668-BA21-4B30-801A-F9906F8D5BBC@ntt-at.com> From: Shida Schubert To: bliss@ietf.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 20 Jan 2009 09:58:13 +0900 X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Subject: [BLISS] Call for interested/ready-to-contribute party in BLISS-REST activity X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: bliss-bounces@ietf.org Errors-To: bliss-bounces@ietf.org All; We would like to spin off another design team for tackling the BLISS-REST framework that was discussed at IETF 73. We will try to hold a regular teleconference to progress the work and ACH design team will remain as it is and it will collect necessary information for realizing the specific data model needed for ACH. I believe we should use BLISS mailing list for discussing the topic so I won't be creating a mailing list for the design team and would like to encourage the use of BLISS mailing list to capture wider audience and feedback. If you are interested in participating in the regular teleconference, please send Jason and I an e-mail expressing your interest. Regards Shida _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jan 26 09:56:35 2009 Return-Path: X-Original-To: bliss-archive@optimus.ietf.org Delivered-To: ietfarch-bliss-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55AC73A6923; Mon, 26 Jan 2009 09:45:57 -0800 (PST) X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BBCD3A6923 for ; Mon, 26 Jan 2009 09:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43tLu6ArOVoW for ; Mon, 26 Jan 2009 09:45:54 -0800 (PST) Received: from relay.ihostexchange.net (relay.ihostexchange.net [66.46.182.51]) by core3.amsl.com (Postfix) with ESMTP id 99B953A67AC for ; Mon, 26 Jan 2009 09:45:51 -0800 (PST) Received: from [10.0.1.69] (67.161.5.213) by smtp.ihostexchange.net (66.46.182.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 26 Jan 2009 12:45:27 -0500 Message-ID: <2814AC59-4DA1-4D1F-B4DE-E8B30691D337@counterpath.com> From: Jason Fischl To: In-Reply-To: <49751EE9.4040005@matthew.at> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 26 Jan 2009 09:45:26 -0800 References: <49751EE9.4040005@matthew.at> X-Mailer: Apple Mail (2.930.3) Cc: bliss@ietf.org Subject: Re: [BLISS] SLA/BLA/MLA history X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: bliss-bounces@ietf.org Errors-To: bliss-bounces@ietf.org Hi Matthew, On Jan 19, 2009, at 4:46 PM, Matthew Kaufman wrote: > I'm looking into the various existing/former ways of handling > {Shared,Bridged} {Call, Line} Appearance to try to figure out who > supports what in existing software/firmware. > > Does anyone know of an existing compilation of which types of > support exist? > Not that I am aware of. > I know of "line-seize"/"call-info" style (documented by Broadsoft) > and two variations of "dialog;sla" style (one of of them documented > by draft-anil-sipping-bla), so far, but perhaps there's more? > > I also have some information about which are supported by which > phones, but I'm sure my knowledge here is weak, because I can't even > figure out 100% what the phone on my own desk supports. (A Polycom > that I know does "line-seize"/"call-info" but claims in > documentation to support draft-anil-sipping-bla-02) and I certainly > don't know what other major vendors do/don't support. > > If such a compilation doesn't exist already, I'd gladly collect > information anyone has and put it together somewhere public. In my > case, I'm trying to write some software that is compatible with at > least one of the previous schemes (preferably whatever was/is most > popular), but it might also be useful as a reference for a future > improved standard. > Yes. This would be very much appreciated. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss