The registrar now processes each contact address in the Contact header field in turn. For each address, it determines the expiration interval as follows: - If the field value has an "expires" parameter, that value MUST be taken as the requested expiration. The registrar MAY choose an expiration less than the requested expiration interval. If and only if the requested expiration interval is greater than zero AND smaller than one hour AND less than a registrar-configured minimum, the registrar MAY reject the registration with a response of Interval Too Brief.
This response MUST contain a Min-Expires header field that states the minimum expiration interval the registrar is willing to honor. It then skips the remaining steps. Allowing the registrar to set the registration interval protects it against excessively frequent registration refreshes while limiting the state that it needs to maintain and decreasing the likelihood of registrations going stale. The expiration interval of a registration is frequently used in the creation of services.
An example is a follow-me service, where the user may only be available at a terminal for a brief period. Therefore, registrars should accept brief registrations; a request should only be rejected if the interval is so short that the refreshes would degrade registrar performance.
If the binding does not exist, it is tentatively added. If the binding does exist, the registrar checks the Call-ID value. If they are the same, the registrar compares the CSeq value. If the value is higher than that of the existing binding, it MUST update or remove the binding as above. If not, the update MUST be aborted and the request fails.
This algorithm ensures that out-of-order requests from the same UA are ignored. The binding updates MUST be committed that is, made visible to the proxy or redirect server if and only if all binding updates and additions succeed. If any one of them fails for example, because the back-end database commit failed , the request MUST fail with a Server Error response and all tentative binding updates MUST be removed.
The registrar returns a OK response. Each Contact value MUST feature an "expires" parameter indicating its expiration interval chosen by the registrar. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. This behavior can be used as a "traceroute" functionality to check the capabilities of individual hop servers by sending a series of OPTIONS requests with incremented Max-Forwards values.
This may indicate that the target is unreachable and hence unavailable. An OPTIONS request received within a dialog generates a OK response that is identical to one constructed outside a dialog and does not have any impact on the dialog. The response does not contain a message body.
Contact header fields MAY be present in a OK response and have the same semantics as in a 3xx response. That is, they may list a set of alternative names and methods of reaching the user. A Warning header field MAY be present. A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them.
The dialog represents a context in which to interpret SIP messages. Section 8 discussed method independent UA processing for requests and responses outside of a dialog. This section discusses how those requests and responses are used to construct a dialog, and then how subsequent requests and responses are sent within a dialog.
The dialog ID at each UA involved in the dialog is not the same. Specifically, the local tag at one UA is identical to the remote tag at the peer UA. The tags are opaque tokens that facilitate the generation of unique dialog IDs. A dialog ID is also associated with all responses and with any request that contains a tag in the To field.
As one would expect for a UAS, the Call-ID value of the dialog ID is set to the Call-ID of the message, the remote tag is set to the tag in the From field of the message, and the local tag is set to the tag in the To field of the message.
A dialog contains certain pieces of state needed for further message transmissions within the dialog. This state consists of the dialog ID, a local sequence number used to order requests from the UA to its peer , a remote sequence number used to order requests from its peer to the UA , a local URI, a remote URI, remote target, a boolean flag called "secure", and a route set, which is an ordered list of URIs.
The route set is the list of servers that need to be traversed to send a request to the peer. A dialog can also be in the "early" state, which occurs when it is created with a provisional response, and then transition to the "confirmed" state when a 2xx final response arrives. For other responses, or if no response arrives at all on that dialog, the early dialog terminates. A dialog established by a non-final response to a request is in the "early" state and it is called an early dialog.
Extensions MAY define other means for creating dialogs. Here, we describe the process for creation of dialog state that is not dependent on the method. If the request that initiated the dialog contained a Rosenberg, et. It can therefore be used in messages to the UAC even outside this dialog. The UAS then constructs the state of the dialog. This state MUST be maintained for the duration of the dialog.
This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The local sequence number MUST be empty.
This is to maintain backwards compatibility with RFC , which did not mandate From tags. This is to maintain backwards compatibility with RFC , which did not mandate To tags.
Note that these may be different roles than the UAs held during the transaction that established the dialog. However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI. Specifically, requests that are not target refresh requests do not modify the dialog's remote target URI, and requests that are target refresh requests do. For dialogs that have been established with an Rosenberg, et.
Other extensions may define different target refresh requests for dialogs established in other ways. Target refresh requests only update the dialog's remote target URI, and not the route set formed from the Record-Route.
Updating the latter would introduce severe backwards compatibility problems with RFC -compliant systems. If the value of the remote or local tags is null, the tag parameter MUST be omitted from the To or From header fields, respectively. In this specification, only the tags are used for dialog identification. It is expected that mandatory reflection of the original To and From URI in mid-dialog requests will be deprecated in a subsequent revision of this specification.
If the local sequence number is empty, an initial value MUST be chosen using the guidelines of Section 8. The initial value of the sequence number is chosen so that subsequent requests within the same call will not wrap around. A non-zero initial value allows clients to use a time- based initial sequence number. A client could, for example, choose the 31 most significant bits of a bit second clock as an initial sequence number.
If the route set is not empty, and the first URI in the route set contains the lr parameter see Section This allows a UA to provide a new contact address, should its address change during the duration of the dialog.
However, requests that are not target refresh requests do not affect the remote target URI for the dialog. The rest of the request is formed as described in Section 8.
Once the request has been constructed, the address of the server is computed and the request is sent, using the same procedures for requests outside of a dialog Section 8. The procedures in Section 8. Subject to certain restrictions, they allow the request to be sent to an alternate address such as a default outbound proxy not represented in the route set.
If the client transaction returns a timeout, this is treated as a Request Timeout response. The behavior of a UAC that receives a 3xx response for a request sent within a dialog is the same as if the request had been sent outside a dialog.
This behavior is described in Section 8. Note, however, that when the UAC tries alternative locations, it still uses the route set for the dialog to build the Route header of the request.
If a particular request is accepted by the UAS, all the state changes associated with it are performed. If the request is rejected, none of the state changes are performed. The UAS will receive the request from the transaction layer. If the request has a tag in the To header field, the UAS core computes the dialog identifier corresponding to the request and compares it with existing dialogs. If there is a match, this is a mid-dialog request. In that case, the UAS first applies the same processing rules for requests outside of a dialog, discussed in Section 8.
If the request has a tag in the To header field, but the dialog identifier does not match any existing dialogs, the UAS may have crashed and restarted, or it may have received a request for a different possibly failed UAS the UASs can construct the To tags so that a UAS can identify that the tag was for a UAS for which it is providing recovery. Another possibility is that the incoming request has been simply misrouted.
Accepting the request for acceptable To tags provides robustness, so that dialogs can persist even through crashes. UAs wishing to support this capability must take into consideration some issues such as choosing monotonically increasing CSeq sequence numbers even across reboots, reconstructing the route set, and accepting out-of-range RTP timestamps and sequence numbers. They are processed as if they had been received outside the dialog. If the remote sequence number is empty, it MUST be set to the value of the sequence number in the CSeq header field value in the request.
If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order and MUST be rejected with a Server Internal Error response. If the remote sequence number was not empty, and the sequence number of the request is greater than the remote sequence number, the request is in order. It is possible for the CSeq sequence number to be higher than the remote sequence number by more than one.
The resubmitted request will have a new CSeq number. Such a gap does not represent any error condition. The mechanism for terminating confirmed dialogs is method specific. In this specification, the BYE method terminates a session and the dialog associated with it. See Section 15 for details. This request may be forwarded by proxies, eventually arriving at one or more UAS that can potentially accept the invitation.
These UASs will frequently need to query the user about whether to accept the Rosenberg, et. After some time, those UASs can accept the invitation meaning the session is to be established by sending a 2xx response. If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is sent, depending on the reason for the rejection.
Before sending a final response, the UAS can also send provisional responses 1xx to advise the UAC of progress in contacting the called user. After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response. The procedure for sending this ACK depends on the type of response.
For final responses between and , the ACK processing is done in the transaction layer and follows one set of rules See Section All these dialogs are part of the same call. An Allow header field Section A Supported header field Section It enumerates all the extensions understood by the UAC. The Accept header field is especially useful for indicating support of various session description formats.
Section 8. There are special rules for message bodies that contain a session description - their corresponding Content-Disposition is "session". The offer indicates the desired communications means audio, video, games , parameters of those means such as codec types and addresses for receiving media from the answerer. The other UA responds with another session description, called the answer, which indicates which communications means are accepted, the parameters that apply to those means, and addresses for receiving media from the offerer.
This results in restrictions on where the offers and answers can appear in SIP messages. The usage of offers and answers is further restricted. In this specification, that is the final 2xx response. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. This means that a UAS based on this specification alone can never generate subsequent offers until completion of the initial transaction. Concretely, the above rules specify two exchanges for UAs compliant to this specification alone - the offer is in the INVITE, and the answer in the 2xx and possibly in a 1xx as well, with the same value , or the offer is in the 2xx, and the answer is in the ACK.
The restrictions of the offer-answer model just described only apply to bodies whose Content-Disposition header field value is "session".
This results in the construction of a client transaction that will ultimately send the request and deliver responses to the UAC. If a provisional response has a tag in the To field, and if the dialog ID of the response does not match an existing dialog, one is constructed using the procedures defined in Section Header fields present in a provisional response are applicable as long as the dialog is in the early state for example, an Allow header field in a provisional response contains the methods that can be used in the dialog while this is in the early state.
Depending on the status code of the 3xx response see Section Subsequent final responses which would only arrive under error conditions MUST be ignored. All early dialogs are considered terminated upon reception of the non-2xx final response. Each response is distinguished by the tag parameter in the To header field, and each represents a distinct dialog, with a distinct dialog identifier.
If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the "confirmed" state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section Otherwise, a new dialog in the "confirmed" state MUST be constructed using the procedures of Section Note that the only piece of state that is recomputed is the route set.
Other pieces of state such as the highest sequence numbers remote and local sent within the dialog are not recomputed. The route set only is recomputed for backwards compatibility. RFC did not mandate mirroring of the Record-Route header field in a 1xx, only 2xx. However, we cannot update the entire state of the dialog, since mid-dialog requests may have been sent within the early dialog, modifying the sequence numbers, for example.
The header fields of the ACK are constructed in the same way as for any request sent within a dialog see Section 12 with the exception of the CSeq and the header fields related to authentication.
Once the ACK has been constructed, the procedures of [ 4 ] are used to determine the destination address, port and transport.
However, the request is passed to the transport layer directly for transmission, rather than a client transaction. At this point all the early dialogs that have not transitioned to established dialogs are terminated.
It first performs the request processing procedures of Section 8. Assuming these processing states are completed without generating a response, the UAS core performs the additional processing steps: 1. When the timer fires, the invitation is considered to be expired. If the request is a mid-dialog request, the method-independent processing described in Section It might also modify the session; Section 14 provides details.
If the request has a tag in the To header field but the dialog identifier does not match any of the existing dialogs, the UAS may have crashed and restarted, or may have received a request for a different possibly failed UAS. Processing from here forward assumes that the INVITE is outside of a dialog, and is thus for the purposes of establishing a new session. This can happen when a user is invited to the same multicast conference by multiple other participants. For example, SDP Rosenberg, et.
If the user is already a member of the session, and the session parameters contained in the session description have not changed, the UAS MAY silently accept the INVITE that is, send a 2xx response without prompting the user.
The UAS can indicate progress, accept, redirect, or reject the invitation. In all of these cases, it formulates a response using the procedures described in Section 8. This is accomplished with a provisional response between and These provisional responses establish early dialogs and therefore follow the procedures of Section However, these will not be delivered reliably.
A proxy has the option of canceling a transaction when there is a gap of 3 minutes between responses in a transaction. To prevent cancellation, the UAS MUST send a non provisional response at every minute, to handle the possibility of lost provisional responses.
An INVITE transaction can go on for extended durations when the user is placed on hold, or when interworking with PSTN systems which allow communications to take place without answering the call. However, it is unlikely that a UAS will be able to know this in general, and thus this response will not usually be used. This response establishes a dialog, and therefore follows the procedures of Section Including these header fields allows the UAC to determine the features and extensions supported by the UAS for the duration of the call, without probing.
Note, however, that the INVITE server transaction will be destroyed as soon as it receives this final response and passes it to the transport. Therefore, it is necessary to periodically pass the response directly to the transport until the ACK arrives. The 2xx response is passed to the transport with an interval that starts at T1 seconds and doubles for each retransmission until it reaches T2 seconds T1 and T2 are defined in Section Response retransmissions cease when an ACK request for the response is received.
This is independent of whatever transport protocols are used to send the response. To ensure reliable delivery across these hops, the response is retransmitted periodically even if the transport at the UAS is reliable.
This is accomplished with a BYE, as described in Section Section 12 explains how to modify an existing dialog using a target refresh request for example, changing the remote target URI of the dialog. This section describes how to modify the actual session. This modification can involve changing addresses or ports, adding a media stream, deleting a media stream, and so on. Either the caller or callee can modify an existing session. The behavior of a UA on detection of media failure is a matter of local policy.
As a result, a UAC that wants to add a media stream, for example, will create a new offer that contains this media stream, and send that in an INVITE request to its peer.
It is important to note that the full description of the session, not just the change, is sent. This supports stateless session processing in various elements, and supports failover and recovery capabilities. If the session description format has the capability for version numbers, the offerer SHOULD indicate that the version of the session description has changed. Note that, as stated in Section If a UA receives a re-INVITE for an existing dialog, it MUST check any version identifiers in the session description or, if there are no version identifiers, the content of the session description to see if it has changed.
If the session description has changed, the UAS MUST adjust the session parameters accordingly, possibly after asking the user for confirmation. Versioning of the session description can be used to accommodate the capabilities of new arrivals to a conference, add or delete media, or change from a unicast to a multicast conference. The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer.
This is to avoid the need for the peer to reject the session description. The state of the session and the state of the dialog are very closely related. As a result, each session is "associated" with a single dialog - the one which resulted in its creation. If an initial INVITE generates a non-2xx final response, that terminates all sessions if any and all dialogs if any that were created through responses to the request.
By virtue of completing the transaction, a non-2xx final response also prevents further sessions from being created as a result of the INVITE. The BYE request is used to terminate a specific session or attempted session. In this case, the specific session is the one with the peer UA on the other side of the dialog.
If no SIP extensions have defined other application layer states associated with the dialog, the BYE also terminates the dialog. The notion of "hanging up" is not well defined within SIP.
It is specific to a particular, albeit common, user interface. Typically, when the user hangs up, it indicates a desire to terminate the attempt to establish a session, and to terminate any sessions already created. This does not mean a user cannot hang up before receipt of the ACK, it just means that the software in his phone needs to maintain state for a short while in order to clean up properly.
If the particular UI allows for the user to reject a call before its answered, a Forbidden is a good way to express that. As per the rules above, a BYE can't be sent. The only case where it can elect not to are multicast sessions, where participation is possible even if the other participant in the dialog has terminated its involvement in the session. A request may traverse several proxies on its way to a UAS. Each will make routing decisions, modifying the request before forwarding it to the next element.
Responses will route through the same set of proxies traversed by the request in the reverse order. Being a proxy is a logical role for a SIP element. When a request arrives, an element that can play the role of a proxy first decides if it needs to respond to the request on its own. For instance, the request may be malformed or the element may need credentials from the client before acting as a proxy. The element MAY respond with any Rosenberg, et.
A proxy can operate in either a stateful or stateless mode for each new request. When stateless, a proxy acts as a simple forwarding element. It forwards each request downstream to a single element determined by making a targeting and routing decision based on the request. It simply forwards every response it receives upstream.
A stateless proxy discards information about a message once the message has been forwarded. A stateful proxy remembers information specifically, transaction state about each incoming request and any requests it sends as a result of processing the incoming request. It uses this information to affect the processing of future messages associated with that request. A stateful proxy MAY choose to "fork" a request, routing it to multiple destinations. Any request that is forwarded to more than one location MUST be handled statefully.
In some circumstances, a proxy MAY forward requests using stateful transports such as TCP without being transaction-stateful. For instance, a proxy MAY forward a request from one TCP connection to another transaction statelessly as long as it places enough information in the message to be able to forward the response down the same connection the request arrived on. Requests forwarded between different types of transports where the proxy's TU must take an active role in ensuring reliable delivery on one of the transports MUST be forwarded transaction statefully.
A stateful proxy MAY transition to stateless operation at any time during the processing of a request, so long as it did not do anything that would otherwise prevent it from being stateless initially forking, for example, or generation of a response. When performing such a transition, all state is simply discarded. Much of the processing involved when acting statelessly or statefully for a request is identical. The next several subsections are written from the point of view of a stateful proxy.
The last section calls out those places where a stateless proxy behaves differently. Its behavior is modeled here in terms of the server and client transactions defined in Section A stateful proxy has a server transaction associated with one or more client transactions by a higher layer proxy processing component see figure 3 , known as a proxy core.
An incoming request is processed by a server Rosenberg, et. Requests from the server transaction are passed to a proxy core. The proxy core determines where to route the request, choosing one or more next-hop locations. An outgoing request for each next-hop location is processed by its own associated client transaction. The proxy core collects the responses from the client transactions and uses them to send responses to the server transaction.
A stateful proxy creates a new server transaction for each new request received. Any retransmissions of the request will then be handled by that server transaction per Section This is a model of proxy behavior, not of software. An implementation is free to take any approach that replicates the external behavior this model defines. For all new requests, including any with unknown methods, an element intending to proxy the request MUST: 1. Validate the request Section Preprocess routing information Section Determine target s for the request Section Forward the request to each target Section Process all responses Section A valid message must pass the following checks: 1.
Reasonable Syntax 2. URI scheme 3. Max-Forwards 4. Optional Loop Detection 5. Proxy-Require 6. The endpoints receiving the requests will resolve the merge as described in Section 8. Reasonable syntax check The request MUST be well-formed enough to be handled with a server transaction. For instance, an element would not reject a request because of a malformed Date header field. Likewise, a proxy would not remove a malformed Date header field before forwarding a request.
This protocol is designed to be extended. Future extensions may define new methods and header fields at any time. If the request does not contain a Max-Forwards header field, this check is passed. If the request contains a Max-Forwards header field with a field value greater than zero, the check is passed. If the request contains a Via header field with a sent- by value that equals a value placed into previous requests by the proxy, the request has been forwarded by this element before. The request has either looped or is legitimately spiraling through the element.
To determine if the request has looped, the element MAY perform the branch parameter calculation described in Step 8 of Section If the parameters match, the request has looped. If they differ, the request is spiraling, and processing continues. Proxy-Require check Future extensions to this protocol may introduce features that require special handling by proxies.
Endpoints will include a Proxy-Require header field in requests that use these features, telling the proxy not to process the request unless the feature is understood. Proxy-Authorization check If an element requires credentials before forwarding a request, the request MUST be inspected as described in Section That section also defines what the element must do if the inspection fails.
The proxy MUST then proceed as if it received this modified request. This will only happen when the element sending the request to the proxy which may have been an endpoint is a strict router. This rewrite on receive is necessary to enable backwards compatibility with those elements. It also allows elements following this specification to preserve the Request-URI through strict-routing proxies see Section This requirement does not obligate a proxy to keep state in order to detect URIs it previously placed in Record-Route header fields.
Instead, a proxy need only place enough information in those URIs to recognize them as values it provided when they later appear.
If the Request-URI contains a maddr parameter, the proxy MUST check to see if its value is in the set of addresses or domains the proxy is configured to be responsible for. If the Request-URI has a maddr parameter with a value the proxy is responsible for, and the request was received using the port and transport indicated explicitly or by default in the Request-URI, the proxy MUST strip the maddr and any non-default port or transport parameter and continue processing as if those values had not been present in the request.
Such a request needs to be forwarded to the proxy using the indicated port and transport. If the first value in the Route header field indicates this proxy, the proxy MUST remove that value from the request.
The set of targets will either be predetermined by the contents of the request or will be obtained from an abstract location service. Each target in the set is represented as a URI. There are many circumstances in which a proxy might receive a request for a domain it is not responsible for. A firewall proxy handling outgoing calls the way HTTP proxies handle outgoing requests is an example of where this is likely to occur. If the target set for the request has not been predetermined as described above, this implies that the element is responsible for the domain in the Request-URI, and the element MAY use whatever mechanism it desires to determine where to send the request.
Any of these mechanisms can be modeled as accessing an abstract Location Service. This may consist of obtaining information from a location service created by a SIP Registrar, reading a database, consulting a presence server, utilizing other protocols, or simply performing an algorithmic substitution on the Request-URI.
The output of these mechanisms is used to construct the target set. Smith company. Any information in or about the request or the current environment of the element MAY be used in the construction of the target set.
For instance, different sets may be constructed depending on contents or the presence of header fields and bodies, the time of day of the request's arrival, the interface on which the request arrived, failure of previous requests, or even the element's current level of utilization. As potential targets are located through these services, their URIs are added to the target set. Targets can only be placed in the target set once. If the proxy is not responsible for that URI, it will not recurse on 3xx or responses as described below.
If the Request-URI of the original request indicates a resource this proxy is responsible for, the proxy MAY continue to add targets to the set after beginning Request Forwarding. It MAY use any information obtained during that processing to determine new targets. For instance, a proxy may choose to incorporate contacts obtained in a redirect response 3xx into the target set.
If a proxy uses a dynamic source of information while building the target set for instance, if it consults a SIP Registrar , it SHOULD monitor that source for the duration of processing the request. Allowing a URI to be added to the set only once reduces unnecessary network traffic, and in the case of incorporating contacts from redirect requests prevents infinite recursion.
The request is sent to a specific next hop proxy for further processing. During request Rosenberg, et. A stateful proxy MAY process the set in any order. It MAY process multiple targets serially, allowing each client transaction to complete before starting the next. It MAY start client transactions with every target in parallel. It also MAY arbitrarily divide the set into groups, processing the groups serially and processing the targets in each group in parallel.
A common ordering mechanism is to use the qvalue parameter of targets obtained from Contact header fields see Section Targets are processed from highest qvalue to lowest.
Targets with equal qvalues may be processed in parallel. A stateful proxy must have a mechanism to maintain the target set as responses are received and associate the responses to each forwarded request with the original request.
For the purposes of this model, this mechanism is a "response context" created by the proxy layer before forwarding the first request. For each target, the proxy forwards the request following these steps: 1. Make a copy of the received request 2. Update the Request-URI 3. Update the Max-Forwards header field 4. Download a free RFC form here. How old are you?
Back Next. Talk to a Disability Lawyer Need a lawyer? Start here. Zip Code. How it Works Briefly tell us about your case Provide your contact information Choose attorneys to contact you. Boost Your Chance of Being Approved. These standards are then supported by various software libraries and tools.
Recommendations: o Use PDF 1. This captures the archivability and long-term stability of PDF 1. There are two subsections: Section 3. Of course, a viewer UI might display processing capabilities, such as showing whether a document has been digitally signed. In many cases, the choice of PDF requirements is heavily influenced by the capabilities of available tools to create PDFs. Most of the discussion of tooling is to be found in Appendix C. They should print well on the widest range of printers and should look good on displays of varying resolution.
There are two paper sizes in common use: "US Letter" 8. Usually, PDF printing software is used in a "shrink to fit" mode where the printing is adjusted to fit the paper in the printer.
There is some controversy, but the argument that A4 is an international standard is compelling. However, if the margins and header positioning are chosen appropriately, the document can be printed without any scaling. However, the margins and header positioning need to be chosen to look good on both paper sizes without scaling.
Following the advice found in [ RFC ], this means that we should use A4 portrait mode with left and right margins of 20 mm, and top and bottom margins of 33 mm. Headers and Footers Page headers and footers are part of the page layout. There are a variety of options. Note that page headers and footers in PDF can be typeset in a way that the entire longer title might fit.
Recommendation: Page headers and footers should contain information similar to the headings in the current text versions of documents, including page numbers, title, author, and date. However, the page headers and footers should be typeset in a way so as to be unobtrusive. The page headers and footers should be placed into the PDF in such a way that they do not interfere with screen readers.
Paragraph Numbering One common feature of the Internet-Draft output formats is optional visible paragraph numbers, to aid in discussions. In the PDF, and thus in the printed rendition, it is possible to make paragraph numbers unobtrusive and even to impinge on the margins. The right margin instead of the left margin prevents the paragraph numbers from being confused with the section numbers. If possible, the paragraph numbers should be coded in such a way that they do not interfere with screen readers.
This is reflected in two areas: running headers and footers, and how text is laid out on a page for optimal reading. Appendix B describes the process of creating a paged document from running text such that related material is present on the same page together and artifacts of pagination don't interfere with easy reading of the document.
Layout engines differ in the quality of the algorithms used to automate these processes. In some cases, the automated processes require some manual assistance to ensure, for example, that a text line intended as a heading is "kept" with the text for which it is a heading.
Recommendations: o Headers and footers should be printed on each page. The information should include the RFC number or Internet-Draft name, the page number, the category e. When a font is not embedded, a PDF viewer will attempt to locate a locally installed font of the same name. If it cannot find an exact match, it will find a "close match".
If a close match is not available, it will fall back to something implementation dependent and usually undesirable. If the HTML version of the document is being visually mimicked, the font s chosen should have both variable-width and constant-width components, as well as bold and italic representations.
Few fonts have glyphs for the entire repertoire of Unicode characters; for this purpose, the PDF generation tool may need a set of fonts and a way of choosing them. Typefaces are typically licensed, and in many cases there is a fee for use by PDF creation tools; however, there is usually no fee for display or print of the embedded fonts.
Recommendations: o For consistent viewing, all fonts should be embedded. The fonts used must be available for use by the IETF community. Some discussion of available typefaces can be found in Appendix C. Hyphenation and Line Breaks Typically, when doing page layout of running text, especially with narrow page width and long words, layout processors of English text often have the option of either hyphenating words or using existing hyphens as a place to introduce word breaks.
However, inserting line breaks mid-word can be harmful when the "word" is actually a sequence of characters representing a protocol element or protocol sequence. Recommendation: Avoid introducing hyphenated line breaks mid-word into the visual display, consistent with requirements for plain text and HTML.
Hyperlinks PDF supports hyperlinks to sections of the same document and also to sections of other documents. The conversion to PDF can generate: o hyperlinks within the document o hyperlinks to other RFCs and Internet-Drafts o hyperlinks to external locations o hyperlinks within a table of contents o hyperlinks within an index Recommendations: o All hyperlinks available in the HTML rendition of the RFC should also be visible and active in the PDF produced.
This includes both internal hyperlinks and hyperlinks to external resources. Section numbers and page numbers in the table of contents should also be hyperlinked to their respective sections in the body of the document. Even so, there are several options.
0コメント