search for: rfc2119

...IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Special permission is granted to remove the above copyright notice, list of conditions, and disclaimer when submitting this document, with or without modification, to the IETF. --> <!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [ <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> <!ENTITY rfc6716 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6716.xml'> <!ENTITY rfc7845 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/...

Tim, Would you mind giving me a more specific example of the sort of document that you think this should look like? I'd like to write up something that is somewhat final. On Mon, May 2, 2016 at 9:30 PM, Michael Graczyk <mgraczyk at google.com> wrote: > On Fri, Apr 29, 2016 at 4:32 PM, Timothy B. Terriberry > <tterribe at xiph.org> wrote: > > As a general point,

...IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Special permission is granted to remove the above copyright notice, list of conditions, and disclaimer when submitting this document, with or without modification, to the IETF. --> <!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [ <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> <!ENTITY rfc6716 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6716.xml'> <!ENTITY rfc7845 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/...

...3.1 RTP Header Payload Type (PT): I don't see an alternative to using a value of the dynamic range (96-127). IIRC, other ranger are reserved for fixed values assigned by IETF. "A dynamic payload type MUST be used - i.e., one in the range [96,127]." 3.2 Payload Header If you refer to RFC2119, please keep the capital letters of your key words. "Reserved, MUST be set to zero" and "this number SHOULD be 0". 4 Frame Packetizing Is it possible to devide these long packets which need fragmentation into smaller ADUs (see [3] RFC2736: minimum units of error recovery)? 5...

Thanks for posting your specdoc, Brandon -- they''re a great example. On 11/21/06, Brandon Keepers <bkeepers at gmail.com> wrote: > > A user purchasing items > - should create an order > - should add to the user''s orders > - should create line items > - should set line item amount to the item''s price > - should set line item amount to 0 if

...ormat from HTML to markdown, I suggest that short term goals on the flac specification focus on: - verifying semantic equalness with the html version - resolving issues that block the mmark/xml2rfc process that generates the RFC formats of the specification - add standard RFC boilerplate (abstract, rfc2119, etc) Dave Rice -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20170512/bb9aa545/attachment.html>

...ximum (4608) value and any intermediate values are not one of >> 192/576/1152/2304/4608/256/512/1024/2048/4096. >> >> The first statement is more restricted. >> >> Is the word "must" to be interpreted as described in RFC 2119 >> (http://www.ietf.org/rfc/rfc2119.txt)? >> >> The second question: >> >> From https://www.xiph.org/flac/documentation_format_overview.html: >> >> The reference encoder uses a single block size for the whole stream >> but the FLAC format does not require it. >> >> Should stream...

I'm misleading about FLAC subset constraints... Please help me understand exact FLAC subset limitation.

...The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC2119 [RFC2119] and > indicate requirement levels for compliant RTP implementations. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >...

...ximum (4608) value and any intermediate values are not one of >> 192/576/1152/2304/4608/256/512/1024/2048/4096. >> >> The first statement is more restricted. >> >> Is the word "must" to be interpreted as described in RFC 2119 >> (http://www.ietf.org/rfc/rfc2119.txt)? >> >> The second question: >> >> From https://www.xiph.org/flac/documentation_format_overview.html: >> >> The reference encoder uses a single block size for the whole stream >> but the FLAC format does not require it. >> >> Should stream...

...ology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119] and indicate requirement levels for compliant RTP implementations. Herlein, et al. Expires November 30, 2007 [Page 5] Internet-Draft Speex May 2007 3. RTP usage for Speex...

Do not forget to add the "Copying conditions" to the RFC. Check http://wiki.debian.org/NonFreeIETFDocuments That page contains a section titled "Template for RFC authors to release additional rights". To follow that guideline a section like the following should be added: x. Copying conditions The author(s) agree to grant third parties the irrevocable right to

...ology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119] and indicate requirement levels for compliant RTP implementations. Herlein, et al. Expires December 7, 2007 [Page 5] Internet-Draft Speex June 2007 3. RTP usage for Speex...

...ximum (4608) value and any intermediate values are not one of >> 192/576/1152/2304/4608/256/512/1024/2048/4096. >> >> The first statement is more restricted. >> >> Is the word "must" to be interpreted as described in RFC 2119 >> (http://www.ietf.org/rfc/rfc2119.txt)? >> >> The second question: >> >> From https://www.xiph.org/flac/documentation_format_overview.html: >> >> The reference encoder uses a single block size for the whole stream >> but the FLAC format does not require it. >> >> Should stream...

...ology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119] and indicate requirement levels for compliant RTP implementations. Herlein, et al. Expires October 24, 2007 [Page 5] Internet-Draft Speex April 2007 3. RTP usage for Speex...

...to markdown, I suggest that short term goals on the flac specification focus on: > - verifying semantic equalness with the html version > - resolving issues that block the mmark/xml2rfc process that generates the RFC formats of the specification > - add standard RFC boilerplate (abstract, rfc2119, etc) To summarize recent work on the FLAC specification, the document has been adjusted in its new markdown format in order to achieve semantic similarity to the original HTML rendition on the xiph.org site. In order to get the structural data (such as the tables at the end of https://xiph.org/fl...

...wn, > I suggest that short term goals on the flac specification focus on: > - verifying semantic equalness with the html version > - resolving issues that block the mmark/xml2rfc process that generates the > RFC formats of the specification > - add standard RFC boilerplate (abstract, rfc2119, etc) > > > To summarize recent work on the FLAC specification, the document has been > adjusted in its new markdown format in order to achieve semantic similarity > to the original HTML rendition on the xiph.org site. In order to get the > structural data (such as the tables at t...

...152/2304/4608/256/512/1024/2048/4096. >>>>>> >>>>>> The first statement is more restricted. >>>>>> >>>>>> Is the word "must" to be interpreted as described in RFC 2119 >>>>>> (http://www.ietf.org/rfc/rfc2119.txt)? >>>>>> >>>>>> The second question: >>>>>> >>>>>> From https://www.xiph.org/flac/documentation_format_overview.html: >>>>>> >>>>>> The reference encoder uses a single block size for the...

...t;>>> >>>>>>>>> The first statement is more restricted. >>>>>>>>> >>>>>>>>> Is the word "must" to be interpreted as described in RFC 2119 >>>>>>>>> (http://www.ietf.org/rfc/rfc2119.txt)? >>>>>>>>> >>>>>>>>> The second question: >>>>>>>>> >>>>>>>>> From https://www.xiph.org/flac/documentation_format_overview.html: >>>>>>>>> >>>>>...

I have 2 groups of machines, and within each group the pxelinux menu configuration is standard. It would be great to have 2 configuration files rather than one for each machine. I found the pxelinux magic option configfile (209) in http://syslinux.zytor.com/wiki/index.php/PXELINUX and it suggests for ISC dhcpd: site-option-space "pxelinux"; option pxelinux.magic