Session Initiation Protocol Service Example -- Music on Hold
draft-worley-service-example-15

[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).

[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.

[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!

[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.

[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.

[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.

[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

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.

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.

(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*

*    '' lines.*

* *

* *

*  Checking references for intended status: Informational*

*  ----------------------------------------------------------------------------*

* *

*  -- Missing reference section? 'Sipping' on line 1528 looks like a reference*

* *

*  -- Missing reference section? 'Sip-implementors' on line 1514 looks like a*

*    reference*

* *

* *

*    Summary: 2 errors (**), 0 flaws (~~), 0 warnings (==), 4 comments (--).*

* *

*    Run idnits with the --verbose option for more detailed information about*

*    the items above.*

* *





(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.



*No formal reviews needed.*





(13) Have all references within this document been identified as either
normative or informative?



*Yes.*





(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?



*No.*





(15) Are there downward normative references references (see RFC 3967)? If
so, list these downward references to support the Area Director in the Last
Call procedure.



*No.*





(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the
document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.



*No.*





(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that newly created IANA registries include a detailed specification of the
initial contents for the registry, that allocations procedures for future
registrations are defined, and a reasonable name for the new registry has
been suggested (see RFC 5226).



*IANA section is not needed.*





(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.



*None.*





(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal language,
such as XML code, BNF rules, MIB definitions, etc.



*None is needed.*


Intended Status changed to
Internet-Draft                    NFSv4                    November 2014

  ///        opaque                  loh_body<>;
  /// };
  ///
  /// enum layoutiomode4 {
  ///        LAYOUTIOMODE4_READ      = 1,
  ///        LAYOUTIOMODE4_RW        = 2,
  ///        LAYOUTIOMODE4_ANY      = 3
  /// };
  ///
  /// struct layout4 {
  ///        offset4                lo_offset;
  ///        length4                lo_length;
  ///        layoutiomode4          lo_iomode;
  ///        layout_content4        lo_content;
  /// };
  ///
  /// const NFS4_DEVICEID4_SIZE = 16;
  ///
  /// typedef opaque  deviceid4[NFS4_DEVICEID4_SIZE];
  ///
  /// struct device_addr4 {
  ///        layouttype4            da_layout_type;
  ///        opaque                  da_addr_body<>;
  /// };
  ///
  ///
  /// struct layoutupdate4 {
  ///        layouttype4            lou_type;
  ///        opaque                  lou_body<>;
  /// };
  ///
  /// %
  /// /* Constants used for LAYOUTRETURN and CB_LAYOUTRECALL */
  /// const LAYOUT4_RET_REC_FILE              = 1;
  /// const LAYOUT4_RET_REC_FSID              = 2;
  /// const LAYOUT4_RET_REC_ALL              = 3;
  /// %
  /// enum layoutreturn_type4 {
  ///        LAYOUTRETURN4_FILE = LAYOUT4_RET_REC_FILE,
  ///        LAYOUTRETURN4_FSID = LAYOUT4_RET_REC_FSID,
  ///        LAYOUTRETURN4_ALL  = LAYOUT4_RET_REC_ALL
  /// };
  ///
  /// struct layoutreturn_file4 {
  ///        offset4        lrf_offset;
  ///        length4        lrf_length;
  ///        stateid4        lrf_stateid;
  /// %      /* layouttype4 specific data */

Haynes                    Expires May 28, 2015                [Page 14]
Internet-Draft                    NFSv4                    November 2014

  ///        opaque          lrf_body<>;
  /// };
  ///
  /// union layoutreturn4 switch(layoutreturn_type4 lr_returntype) {
  ///        case LAYOUTRETURN4_FILE:
  ///                layoutreturn_file4      lr_layout;
  ///        default:
  ///                void;
  /// };
  /// %
  ///
  /// enum fs4_status_type {
  ///        STATUS4_FIXED = 1,
  ///        STATUS4_UPDATED = 2,
  ///        STATUS4_VERSIONED = 3,
  ///        STATUS4_WRITABLE = 4,
  ///        STATUS4_REFERRAL = 5
  /// };
  ///
  /// struct fs4_status {
  ///        bool            fss_absent;
  ///        fs4_status_type fss_type;
  ///        utf8str_cs      fss_source;
  ///        utf8str_cs      fss_current;
  ///        int32_t        fss_age;
  ///        nfstime4        fss_version;
  /// };
  ///
  ///
  /// const TH4_READ_SIZE    = 0;
  /// const TH4_WRITE_SIZE    = 1;
  /// const TH4_READ_IOSIZE  = 2;
  /// const TH4_WRITE_IOSIZE  = 3;
  ///
  /// typedef length4 threshold4_read_size;
  /// typedef length4 threshold4_write_size;
  /// typedef length4 threshold4_read_iosize;
  /// typedef length4 threshold4_write_iosize;
  ///
  /// struct threshold_item4 {
  ///        layouttype4    thi_layout_type;
  ///        bitmap4        thi_hintset;
  ///        opaque          thi_hintlist<>;
  /// };
  ///
  /// struct mdsthreshold4 {
  ///        threshold_item4 mth_hints<>;
  /// };

Haynes                    Expires May 28, 2015                [Page 15]
Internet-Draft                    NFSv4                    November 2014

  ///
  /// const RET4_DURATION_INFINITE    = 0xffffffffffffffff;
  /// struct retention_get4 {
  ///        uint64_t        rg_duration;
  ///        nfstime4        rg_begin_time<1>;
  /// };
  ///
  /// struct retention_set4 {
  ///        bool            rs_enable;
  ///        uint64_t        rs_duration<1>;
  /// };
  ///
  /// const FSCHARSET_CAP4_CONTAINS_NON_UTF8  = 0x1;
  /// const FSCHARSET_CAP4_ALLOWS_ONLY_UTF8  = 0x2;
  ///
  /// typedef uint32_t        fs_charset_cap4;
  ///
  ///
  /// /*
  ///  * data structures new to NFSv4.2
  ///  */
  ///
  /// enum netloc_type4 {
  ///        NL4_NAME        = 0,
  ///        NL4_URL        = 1,
  ///        NL4_NETADDR    = 2
  /// };
  /// union netloc4 switch (netloc_type4 nl_type) {
  ///        case NL4_NAME:          utf8str_cis nl_name;
  ///        case NL4_URL:          utf8str_cis nl_url;
  ///        case NL4_NETADDR:      netaddr4    nl_addr;
  /// };
  ///
  /// enum change_attr_type4 {
  ///            NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR        = 0,
  ///            NFS4_CHANGE_TYPE_IS_VERSION_COUNTER        = 1,
  ///            NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS = 2,
  ///            NFS4_CHANGE_TYPE_IS_TIME_METADATA          = 3,
  ///            NFS4_CHANGE_TYPE_IS_UNDEFINED              = 4
  /// };
  ///
  /// struct labelformat_spec4 {
  ///        policy4 lfs_lfs;
  ///        policy4 lfs_pi;
  /// };
  ///
  /// struct sec_label4 {
  ///        labelformat_spec4      slai_lfs;

Haynes                    Expires May 28, 2015                [Page 16]
Internet-Draft                    NFSv4                    November 2014

  ///        opaque                  slai_data<>;
  /// };
  ///
  ///
  /// struct copy_from_auth_priv {
  ///        secret4            cfap_shared_secret;
  ///        netloc4            cfap_destination;
  ///        /* the NFSv4 user name that the user principal maps to */
  ///        utf8str_mixed      cfap_username;
  /// };
  ///
  /// struct copy_to_auth_priv {
  ///        /* equal to cfap_shared_secret */
  ///        secret4              ctap_shared_secret;
  ///        netloc4              ctap_source<>;
  ///        /* the NFSv4 user name that the user principal maps to */
  ///        utf8str_mixed        ctap_username;
  /// };
  ///
  /// struct copy_confirm_auth_priv {
  ///        /* equal to GSS_GetMIC() of cfap_shared_secret */
  ///        opaque              ccap_shared_secret_mic<>;
  ///        /* the NFSv4 user name that the user principal maps to */
  ///        utf8str_mixed      ccap_username;
  /// };
  ///
  ///
  /// struct app_data_block4 {
  ///        offset4        adb_offset;
  ///        length4        adb_block_size;
  ///        length4        adb_block_count;
  ///        length4        adb_reloff_blocknum;
  ///        count4          adb_block_num;
  ///        length4        adb_reloff_pattern;
  ///        opaque          adb_pattern<>;
  /// };
  ///
  ///
  /// struct data4 {
  ///        offset4        d_offset;
  ///        opaque          d_data<>;
  /// };
  ///
  /// struct data_info4 {
  ///        offset4        di_offset;
  ///        length4        di_length;
  /// };
  ///

Haynes                    Expires May 28, 2015                [Page 17]
Internet-Draft                    NFSv4                    November 2014

  ///
  /// enum data_content4 {
  ///        NFS4_CONTENT_DATA = 0,
  ///        NFS4_CONTENT_HOLE = 1
  /// };
  ///
  ///
  ///
  /// enum stable_how4 {
  ///        UNSTABLE4      = 0,
  ///        DATA_SYNC4      = 1,
  ///        FILE_SYNC4      = 2
  /// };
  ///
  ///
  ///
  /// struct write_response4 {
  ///        stateid4        wr_callback_id<1>;
  ///        length4        wr_count;
  ///        stable_how4    wr_committed;
  ///        verifier4      wr_writeverf;
  /// };
  ///
  ///
  /// /*
  ///  * NFSv4.1 attributes
  ///  */
  /// typedef bitmap4        fattr4_supported_attrs;
  /// typedef nfs_ftype4      fattr4_type;
  /// typedef uint32_t        fattr4_fh_expire_type;
  /// typedef changeid4      fattr4_change;
  /// typedef uint64_t        fattr4_size;
  /// typedef bool            fattr4_link_support;
  /// typedef bool            fattr4_symlink_support;
  /// typedef bool            fattr4_named_attr;
  /// typedef fsid4          fattr4_fsid;
  /// typedef bool            fattr4_unique_handles;
  /// typedef nfs_lease4      fattr4_lease_time;
  /// typedef nfsstat4        fattr4_rdattr_error;
  /// typedef nfsace4        fattr4_acl<>;
  /// typedef uint32_t        fattr4_aclsupport;
  /// typedef bool            fattr4_archive;
  /// typedef bool            fattr4_cansettime;
  /// typedef bool            fattr4_case_insensitive;
  /// typedef bool            fattr4_case_preserving;
  /// typedef bool            fattr4_chown_restricted;
  /// typedef uint64_t        fattr4_fileid;
  /// typedef uint64_t        fattr4_files_avail;

Haynes                    Expires May 28, 2015                [Page 18]
Internet-Draft                    NFSv4                    November 2014

  /// typedef nfs_fh4        fattr4_filehandle;
  /// typedef uint64_t        fattr4_files_free;
  /// typedef uint64_t        fattr4_files_total;
  /// typedef fs_locations4  fattr4_fs_locations;
  /// typedef bool            fattr4_hidden;
  /// typedef bool            fattr4_homogeneous;
  /// typedef uint64_t        fattr4_maxfilesize;
  /// typedef uint32_t        fattr4_maxlink;
  /// typedef uint32_t        fattr4_maxname;
  /// typedef uint64_t        fattr4_maxread;
  /// typedef uint64_t        fattr4_maxwrite;
  /// typedef ascii_REQUIRED4 fattr4_mimetype;
  /// typedef mode4          fattr4_mode;
  /// typedef mode_masked4    fattr4_mode_set_masked;
  /// typedef uint64_t        fattr4_mounted_on_fileid;
  /// typedef bool            fattr4_no_trunc;
  /// typedef uint32_t        fattr4_numlinks;
  /// typedef utf8str_mixed  fattr4_owner;
  /// typedef utf8str_mixed  fattr4_owner_group;
  /// typedef uint64_t        fattr4_quota_avail_hard;
  /// typedef uint64_t        fattr4_quota_avail_soft;
  /// typedef uint64_t        fattr4_quota_used;
  /// typedef specdata4      fattr4_rawdev;
  /// typedef uint64_t        fattr4_space_avail;
  /// typedef uint64_t        fattr4_space_free;
  /// typedef uint64_t        fattr4_space_total;
  /// typedef uint64_t        fattr4_space_used;
  /// typedef bool            fattr4_system;
  /// typedef nfstime4        fattr4_time_access;
  /// typedef settime4        fattr4_time_access_set;
  /// typedef nfstime4        fattr4_time_backup;
  /// typedef nfstime4        fattr4_time_create;
  /// typedef nfstime4        fattr4_time_delta;
  /// typedef nfstime4        fattr4_time_metadata;
  /// typedef nfstime4        fattr4_time_modify;
  /// typedef settime4        fattr4_time_modify_set;
  /// /*
  ///  * attributes new to NFSv4.1
  ///  */
  /// typedef bitmap4        fattr4_suppattr_exclcreat;
  /// typedef nfstime4        fattr4_dir_notif_delay;
  /// typedef nfstime4        fattr4_dirent_notif_delay;
  /// typedef layouttype4    fattr4_fs_layout_types<>;
  /// typedef fs4_status      fattr4_fs_status;
  /// typedef fs_charset_cap4 fattr4_fs_charset_cap;
  /// typedef uint32_t        fattr4_layout_alignment;
  /// typedef uint32_t        fattr4_layout_blksize;
  /// typedef layouthint4    fattr4_layout_hint;

Informational