Session Initiation Protocol Service Example -- Music on Hold
draft-worley-service-example-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-02-04
|
15 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-12-10
|
15 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-12-03
|
15 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-11-08
|
15 | Dale Worley | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2013-11-08
|
15 | Dale Worley | New version available: draft-worley-service-example-15.txt |
2013-10-30
|
14 | (System) | IANA Action state changed to No IC from In Progress |
2013-10-29
|
14 | (System) | IANA Action state changed to In Progress |
2013-10-29
|
14 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2013-10-29
|
14 | (System) | RFC Editor state changed to EDIT |
2013-10-29
|
14 | (System) | Announcement was received by RFC Editor |
2013-10-29
|
14 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-10-29
|
14 | Amy Vezza | IESG has approved the document |
2013-10-29
|
14 | Amy Vezza | Closed "Approve" ballot |
2013-10-29
|
14 | Amy Vezza | Ballot approval text was generated |
2013-10-29
|
14 | Amy Vezza | Ballot writeup was changed |
2013-10-29
|
14 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2013-10-29
|
14 | Amy Vezza | Document shepherd changed to Rifaat Shekh-Yusef |
2013-10-28
|
14 | Ted Lemon | [Ballot Position Update] Position for Ted Lemon has been changed to No Objection from Discuss |
2013-10-23
|
14 | Suresh Krishnan | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Suresh Krishnan. |
2013-10-10
|
14 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2013-10-10
|
14 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2013-10-10
|
14 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-10-10
|
14 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-10-10
|
14 | Stephen Farrell | [Ballot comment] - abstract: Music on hold? Sorry, but yuk, so "most desired" is not something I find credible unless you care to say who … [Ballot comment] - abstract: Music on hold? Sorry, but yuk, so "most desired" is not something I find credible unless you care to say who desires it any why. "Fully effective" is also just marketing. And "standards compliant" is also an odd thing to say - why should we note that? - I recently used some concall service that told me "if you don't want the music, hit 1" which is nice. If that isn't the content of someone's really dumb patent, it'd be a service to humanity to include that feature here. - The security considerations are very thorough, thanks. However, it'd be better if you said "this will break any security setup for the call unless the MOH and executing UA are in the same domain and indistinguishable from the remote UA's perspective." It'd be a real shame for this feature to be something the precluded introducing some e2e security into SIP. (This isn't a discuss only because it seems e2e security for SIP calls seems mythical right now and this is informational. If this does need to be standards track I might promote this to a discuss calling for there to be a way to ensure that MOH doesn't weaken whatever security is in place for the call). |
2013-10-10
|
14 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2013-10-10
|
14 | Ted Lemon | [Ballot discuss] I've realized upon reflection that some of the comments I've made in the comments section are actually DISCUSS-worthy. I don't want to block … [Ballot discuss] I've realized upon reflection that some of the comments I've made in the comments section are actually DISCUSS-worthy. I don't want to block forward motion on this document, and if the resolution on the telechat today is that nobody else cares about this, I will clear the DISCUSS on that basis, but: 1. I _really_ think this is a standard, not informational, and consequently 2. I think the point I raised in the comment section about section 2.8.1 is actually an interoperability problem that needs to be addressed. So, I will clear this DISCUSS if any of the following happen: 1. There is no consensus on the telechat that this needs to be addressed. 2. The hack described in section 2.8 is made mandatory (that is, the language in 2.8.1 that says it's not mandatory is removed). 3. There is consensus that the requirement that's mentioned in 2.8.1 really is unnecessary, in which case the hack should just not be documented. |
2013-10-10
|
14 | Ted Lemon | [Ballot Position Update] Position for Ted Lemon has been changed to Discuss from No Objection |
2013-10-10
|
14 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-10-10
|
14 | Ted Lemon | [Ballot comment] I think the text in the introduction about why people want on hold music is better than the text in the Abstract; I … [Ballot comment] I think the text in the introduction about why people want on hold music is better than the text in the Abstract; I mention this because several other ADs commented on the abstract text, which I too found to be excessively exuberant on the topic of how much people like on hold music. No need to change it unless you take all this whining to heart. I agree with Pete that if this document lives up to its sales pitch, it ought to be either experimental or proposed standard, not informational. The motivation for calling it informational seems to be that it isn't intended to supersede other methods, but that's not a reason for it to be informational. That's just a reason not to put "Obsoletes RFCxxxx" on the title page. I'm curious to know if you talked this over with Richard, or if it just passed under the radar. In section 2, the links to RFC 4566 and RFC 3264 are broken, but the link to RFC 6337 is working. I don't know what happened here, but you should fix this in your source so that they all work, assuming it's not a bug in xml2rfc. In section 2.5, it looks like what's happening here is that Alice has transferred the call to Carol. Is that correct? If so, you might want to say that. I suppose a reader who's experience with SIP will understand this, but it was a bit mysterious to me, and I think saying what is happening makes it clearer. Not all readers are wizards. (If I _knew_ that I'd understood it correctly, I would not have made this comment; the problem is that the text does not confirm my supposition, so I don't know whether or not it is correct.) Actually, reading section 2.6 suggests to me that I haven't got it right. I think 2.5 and 2.6 would benefit from an explanation of what user action triggered the described protocol behavior. Section 2.7 has another broken external reference, to RFC 5245. It's possible that I've missed other such references on the way through the document—if you figure out why this is happening, you should probably check for instances I've missed. You also have several broken cross-document section references in 2.8.1. This suggests to me that it's the tools HTML reader that's at fault here, but if you are using xml2rfc, it would be good if you could use the xml2rfc technique for doing cross-document section references, so that these do the right thing when the reader clicks on them. If you aren't using xml2rfc, this can be left to the RFC editor. BTW, the link to section 6.3 of RFC 3264 that immediately precedes the 2.8.3 section header is rendered correctly, so one way to address this comment would be to reformat the other cross-document section references so that they look like this one. Also, it occurs to me that the broken references elsewhere in the document may be broken because there is no whitespace before the opening square bracket: foo[RFCxxx] rather than foo [RFCxxx]. The conclusion of section 2.8.1 is a bit unhelpful. It seems to me that the implementor of a user agent can't really know whether or not the solution described in later portions of section 2.8 is needed, and indeed there's no way to tell from the protocol either. So the document should either recommend always implementing the solution you describe here, or shouldn't recommend it. It seems to me that you, an expert in the field, think that this hack is unnecessary, and are including it merely for completeness. If that's the case, it would be good to say so. It would help to understand why the requirement you are working around here was stated in the first place. If you really can't be sure this hack is not required, then it should probably be required, even if in most cases it's unnecessary. In 5.2: The executing UA and the MOH server will usually be within the same administrative domain and the SIP signaling path between them will lie entirely within that domain. In this case, the administrator of the domain should configure the UA and server to apply to to the dialog between them a level of security that is appropriate for the administrative domain. You have a doubled "to" toward the end of the fourth line. All in all a very readable and understandable document—thanks for doing it! |
2013-10-10
|
14 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2013-10-09
|
14 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2013-10-09
|
14 | Pete Resnick | [Ballot comment] I'd like to understand why this document is not being put forward as either Proposed Standard or Experimental. This document does describe protocol. … [Ballot comment] I'd like to understand why this document is not being put forward as either Proposed Standard or Experimental. This document does describe protocol. It may be updated in the future if there are certain parts of the protocol exchange that need to be changed or clarified. It might become the one and only standard way that people do MOH. It doesn't matter that there are other ways to to MOH; it's that this is one good (maybe the best) way to do it. Section 1.1 doesn't really explain why you didn't go for PS or Exp. (I certainly agree that this ought not have been BCP.) If it goes forward as Informational, the world doesn't end. But it seems like a non-ideal choice. I agree with Barry that either way, 1.1 probably doesn't need to be in the final RFC. |
2013-10-09
|
14 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-10-09
|
14 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-10-09
|
14 | Stewart Bryant | [Ballot comment] I agree with Adrian's note, as MoH is my most unfavorite feature, reminding me of the time and money I am wasting due … [Ballot comment] I agree with Adrian's note, as MoH is my most unfavorite feature, reminding me of the time and money I am wasting due to the lack of call center capacity at the called party. Don't some codecs require "speech on hold"? I neither require nor anticipate any change based on the above comments. |
2013-10-09
|
14 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-10-09
|
14 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-10-08
|
14 | Barry Leiba | [Ballot comment] A couple of very minor, non-blocking comments; please consider them, and there's no need to reply. -- Section 1.1 -- Much discussion of … [Ballot comment] A couple of very minor, non-blocking comments; please consider them, and there's no need to reply. -- Section 1.1 -- Much discussion of the intended status, and why this isn't a BCP or whatever, may have been useful during the development of the document and its review by the community and the IESG, but probably doesn't have archival value. I suggest adding the last paragraph, minus the word "however", to the end of the second paragraph of Section 1. I suggest moving the second paragraph to be a new third paragraph of Section 1. That will leave the first paragraph, to which I suggest you add a note to the RFC Editor to remove this section on publication. -- Section 6 -- The citations to mailing list messages are interesting. I'm not sure I've seen it done before, but I think it's probably useful. That said, I think it'd be more useful if the references contained URIs for the messages, rather than just the message numbers. |
2013-10-08
|
14 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-10-08
|
14 | Adrian Farrel | [Ballot comment] Delightful document although I take issue with the very first statement: > The "music on hold" feature is one of the most desired … [Ballot comment] Delightful document although I take issue with the very first statement: > The "music on hold" feature is one of the most desired features of > telephone systems in the business environment. I get pretty annoyed by it. Especially bad music on a short loop with poor quality audio. :-) --- A number of key fields have not be filled in to the data tracker. Of particular importance is the "IETF consensus" field |
2013-10-08
|
14 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-10-07
|
14 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2013-10-03
|
14 | Jean Mahoney | Request for Telechat review by GENART is assigned to Suresh Krishnan |
2013-10-03
|
14 | Jean Mahoney | Request for Telechat review by GENART is assigned to Suresh Krishnan |
2013-10-02
|
14 | Dale Worley | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2013-10-02
|
14 | Dale Worley | New version available: draft-worley-service-example-14.txt |
2013-09-13
|
13 | Richard Barnes | Ballot has been issued |
2013-09-13
|
13 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2013-09-13
|
13 | Richard Barnes | Created "Approve" ballot |
2013-09-13
|
13 | Richard Barnes | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2013-09-13
|
13 | Richard Barnes | Placed on agenda for telechat - 2013-10-10 |
2013-09-13
|
13 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call (ends 2013-09-13) |
2013-09-05
|
13 | Richard Barnes | Ballot approval text was generated |
2013-08-29
|
13 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Stephen Kent. |
2013-08-22
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2013-08-22
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2013-08-22
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2013-08-22
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2013-08-20
|
13 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2013-08-20
|
13 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-worley-service-example-13, which is currently in Last Call, and has the following comments: IANA notes that this document does not … IESG/Authors/WG Chairs: IANA has reviewed draft-worley-service-example-13, which is currently in Last Call, and has the following comments: IANA notes that this document does not contain a standard IANA Considerations section. However, we understand that this document doesn't require any IANA actions. If this assessment is not accurate, please respond as soon as possible. |
2013-08-16
|
13 | Maddy Conner | IANA Review state changed to IANA - Review Needed |
2013-08-16
|
13 | Maddy Conner | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Session Initiation Protocol Service Example -- … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Session Initiation Protocol Service Example -- Music on Hold) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Session Initiation Protocol Service Example -- Music on Hold' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The "music on hold" feature is one of the most desired features of telephone systems in the business environment. "Music on hold" is where, when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The implementation of music-on-hold described in this document is fully effective and standards-compliant, and has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems which perform authentication than the music-on-hold method described in section 2.3 of RFC 5359. The file can be obtained via http://datatracker.ietf.org/doc/draft-worley-service-example/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-worley-service-example/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-08-16
|
13 | Maddy Conner | State changed to In Last Call from Last Call Requested |
2013-08-16
|
13 | Richard Barnes | Last call was requested |
2013-08-16
|
13 | Richard Barnes | Ballot approval text was generated |
2013-08-16
|
13 | Richard Barnes | State changed to Last Call Requested from AD Evaluation |
2013-08-16
|
13 | Richard Barnes | Ballot writeup was changed |
2013-08-16
|
13 | Richard Barnes | Changed document writeup |
2013-08-16
|
13 | Richard Barnes | Ballot writeup was generated |
2013-08-16
|
13 | Richard Barnes | Last call announcement was generated |
2013-06-25
|
13 | Dale Worley | New version available: draft-worley-service-example-13.txt |
2013-06-21
|
12 | Richard Barnes | State changed to AD Evaluation from Publication Requested |
2013-04-22
|
12 | Cindy Morgan | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? *Informational.* * * *See section 1.1 of the draft for more details around the reason behind this choice.*** (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: *The "music on hold" feature is one of the most desired features of telephone systems in the business environment. "Music on hold" is where, when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The implementation of music-on-hold described in this document is fully effective and standards-compliant, and has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems which perform authentication than the music-on-hold method described in section 2.3 of RFC 5359.* Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? *This document is not the product of a working group. However, the document has been discussed in the SIPPING and SIPCORE working group and got feedback from the sip-implementors mailing list.* * * * * Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? *It seems that there are many implementations out there for this mechanism:* *Dale believes that Polycom SIP phones use this technique.* * * *Dale also got the following response from John Riordan at Junction Networks related to their OnSIP hosted PBX:* * John Riordan at Junction Networks <**john@junctionnetworks.com* *> reports:** >> We've been running production MOH services on this for years now and >> user agents produced by significant companies have supported it for >> a while. and: >> Good to hear. And I would be happy to be used as a reference.*** * * * * *John Riordan (of Junction Networks) reports that Cisco/Linksys SPA** phones use this system, but apparently Cisco does not document it: From: John Riordan <**john@riordan.org**>** Subject: Re: Mail regarding draft-worley-service-example Date: Fri, 19 Apr 2013 10:58:55 -0400 Cisco's "SPA" models implement it, however we are not aware of any Cisco documentation that references 'worley'. These models were originally sold under the 'Linksys' brand. There are instructions on configuring MoH in manuals - for example page 96 of ** http://www.cisco.com/en/US/docs/voice_ip_comm/csbpipp/ip_phones/administration/guide/spa500_admin.pdf ** - but there is no reference to worley that we've seen. We discovered support during our phone evaluation process - we have a little testing lab that reviews user agents from all over the place and follows a process similar to **http://wiki.sipfoundry.org/display/sipXecs/Phone+Certification+Process * * * * * * * *The phone certification process for SIPxecs PBX** (**http://wiki.sipfoundry.org/display/sipXecs/Phone+Certification+Process**) ** lists draft-worley-service-example-09 as the relevant standard for music-on-hold. (-09 is technically the same as -12.)* * * * * * * *Personnel:* * * *Document Shepherd: Rifaat Shekh-Yusef* *Responsible Area Director: Richard Barnes* (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. *The shepherd has reviewed version 11 of the document (** http://tools.ietf.org/html/draft-worley-service-example-11* *) and provided feedback to the author. The author corrected, improved, and added more details to various areas in the document based on that feedback.* *The Sheppard has reviewed version 12 (** https://datatracker.ietf.org/doc/draft-worley-service-example/?include_text=1 * *) of the document for technical quality and completeness. The document is ready to be considered by the IESG.* (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? *No.* (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. *No.* (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. *None.* (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? *Yes.* (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. *No.* (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? *This document is not the product of a working group. However, it has been reviewed and discussed by a number of key contributors in the SIPPING and SIPCORE working groups and received feedback from the sip-implementors mailing list. * *See section 8.2 Informative References for more information on the feedback provided by various contributors.* * * (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) *No.* (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. *Checking nits according to http://www.ietf.org/id-info/checklist :* * ----------------------------------------------------------------------------* * * * ** The document seems to lack an IANA Considerations section. (See Section* * 2.2 of http://www.ietf.org/id-info/checklist for how to handle the case* * when there are no actions for IANA.)* * * * ** The document seems to lack a both a reference to RFC 2119 and the* * recommended RFC 2119 boilerplate, even if it appears to use RFC 2119* * keywords. * * * * RFC 2119 keyword, line 838: '...e indicates "the request SHOULD NOT be...'* * RFC 2119 keyword, line 902: '...load type number SHOULD be used for th...'* * * * Miscellaneous warnings:* * ----------------------------------------------------------------------------* * * * -- The document seems to lack a disclaimer for pre-RFC5378 work, but may* * have content which was first submitted before 10 November 2008. If you* * have contacted all the original authors and they are all willing to grant* * the BCP78 rights to the IETF Trust, then this is fine, and you can ignore* * this comment. If not, you may need to add the pre-RFC5378 disclaimer. * * (See the Legal Provisions document at* * http://trustee.ietf.org/license-info for more information.)* * * * -- Found something which looks like a code comment -- if you have code* * sections in the document, please surround them with ' ' and* |
2013-04-22
|
12 | Cindy Morgan | Note added 'Rifaat Shekh-Yusef (rifaat.sy@gmail.com) is the document shepherd.' |
2013-04-22
|
12 | Cindy Morgan | State Change Notice email list changed to worley@ariadne.com, draft-worley-service-example@tools.ietf.org, rifaat.sy@gmail.com |
2013-04-22
|
12 | Cindy Morgan | Intended Status changed to Informational |
2013-04-22
|
12 | Cindy Morgan | IESG process started in state Publication Requested |
2013-04-22
|
12 | Cindy Morgan | Stream changed to IETF from None |
2013-04-16
|
12 | Dale Worley | New version available: draft-worley-service-example-12.txt |
2013-02-20
|
11 | Dale Worley | New version available: draft-worley-service-example-11.txt |
2012-08-16
|
10 | Dale Worley | New version available: draft-worley-service-example-10.txt |
2012-02-13
|
09 | (System) | New version available: draft-worley-service-example-09.txt |
2011-08-22
|
08 | (System) | New version available: draft-worley-service-example-08.txt |
2011-07-06
|
07 | (System) | New version available: draft-worley-service-example-07.txt |
2011-07-02
|
09 | (System) | Document has expired |
2010-12-29
|
06 | (System) | New version available: draft-worley-service-example-06.txt |
2010-07-11
|
05 | (System) | New version available: draft-worley-service-example-05.txt |
2009-10-26
|
04 | (System) | New version available: draft-worley-service-example-04.txt |
2009-03-06
|
03 | (System) | New version available: draft-worley-service-example-03.txt |
2008-08-28
|
02 | (System) | New version available: draft-worley-service-example-02.txt |
2008-01-16
|
01 | (System) | New version available: draft-worley-service-example-01.txt |
2007-11-08
|
00 | (System) | New version available: draft-worley-service-example-00.txt |