En bilbao, claro
lunes, 1 de marzo de 2010
miércoles, 24 de febrero de 2010
PA TRADUCIR
4.1. Miscellaneous obsolete tokens
These syntactic elements are used elsewhere in the obsolete syntax or
in the main syntax. The obs-char and obs-qp elements each add ASCII
value 0. Bare CR and bare LF are added to obs-text and obs-utext.
The period character is added to obs-phrase. The obs-phrase-list
provides for "empty" elements in a comma-separated list of phrases.
Note: The "period" (or "full stop") character (".") in obs-phrase is
not a form that was allowed in earlier versions of this or any other
standard. Period (nor any other character from specials) was not
allowed in phrase because it introduced a parsing difficulty
distinguishing between phrases and portions of an addr-spec (see
section 4.4). It appears here because the period character is
currently used in many messages in the display-name portion of
addresses, especially for initials in names, and therefore must be
interpreted properly. In the future, period may appear in the
regular syntax of phrase.
obs-qp = "\" (%d0-127)
obs-text = *LF *CR *(obs-char *LF *CR)
obs-char = %d0-9 / %d11 / ; %d0-127 except CR and
%d12 / %d14-127 ; LF
obs-utext = obs-text
obs-phrase = word *(word / "." / CFWS)
obs-phrase-list = phrase / 1*([phrase] [CFWS] "," [CFWS]) [phrase]
Bare CR and bare LF appear in messages with two different meanings.
In many cases, bare CR or bare LF are used improperly instead of CRLF
to indicate line separators. In other cases, bare CR and bare LF are
used simply as ASCII control characters with their traditional ASCII
meanings.
4.2. Obsolete folding white space
In the obsolete syntax, any amount of folding white space MAY be
inserted where the obs-FWS rule is allowed. This creates the
possibility of having two consecutive "folds" in a line, and
therefore the possibility that a line which makes up a folded header
field could be composed entirely of white space.
obs-FWS = 1*WSP *(CRLF 1*WSP)
4.3. Obsolete Date and Time
The syntax for the obsolete date format allows a 2 digit year in the
date field and allows for a list of alphabetic time zone
specifications that were used in earlier versions of this standard.
It also permits comments and folding white space between many of the
tokens.
obs-day-of-week = [CFWS] day-name [CFWS]
obs-year = [CFWS] 2*DIGIT [CFWS]
obs-month = CFWS month-name CFWS
obs-day = [CFWS] 1*2DIGIT [CFWS]
obs-hour = [CFWS] 2DIGIT [CFWS]
obs-minute = [CFWS] 2DIGIT [CFWS]
obs-second = [CFWS] 2DIGIT [CFWS]
obs-zone = "UT" / "GMT" / ; Universal Time
; North American UT
; offsets
"EST" / "EDT" / ; Eastern: - 5/ - 4
"CST" / "CDT" / ; Central: - 6/ - 5
"MST" / "MDT" / ; Mountain: - 7/ - 6
"PST" / "PDT" / ; Pacific: - 8/ - 7
%d65-73 / ; Military zones - "A"
%d75-90 / ; through "I" and "K"
%d97-105 / ; through "Z", both
%d107-122 ; upper and lower case
Where a two or three digit year occurs in a date, the year is to be
interpreted as follows: If a two digit year is encountered whose
value is between 00 and 49, the year is interpreted by adding 2000,
ending up with a value between 2000 and 2049. If a two digit year is
encountered with a value between 50 and 99, or any three digit year
is encountered, the year is interpreted by adding 1900.
In the obsolete time zone, "UT" and "GMT" are indications of
"Universal Time" and "Greenwich Mean Time" respectively and are both
semantically identical to "+0000".
The remaining three character zones are the US time zones. The first
letter, "E", "C", "M", or "P" stands for "Eastern", "Central",
"Mountain" and "Pacific". The second letter is either "S" for
"Standard" time, or "D" for "Daylight" (or summer) time. Their
interpretations are as follows:
EDT is semantically equivalent to -0400
EST is semantically equivalent to -0500
CDT is semantically equivalent to -0500
CST is semantically equivalent to -0600
MDT is semantically equivalent to -0600
MST is semantically equivalent to -0700
PDT is semantically equivalent to -0700
PST is semantically equivalent to -0800
The 1 character military time zones were defined in a non-standard
way in [RFC822] and are therefore unpredictable in their meaning.
The original definitions of the military zones "A" through "I" are
equivalent to "+0100" through "+0900" respectively; "K", "L", and "M"
are equivalent to "+1000", "+1100", and "+1200" respectively; "N"
through "Y" are equivalent to "-0100" through "-1200" respectively;
and "Z" is equivalent to "+0000". However, because of the error in
[RFC822], they SHOULD all be considered equivalent to "-0000" unless
there is out-of-band information confirming their meaning.
Other multi-character (usually between 3 and 5) alphabetic time zones
have been used in Internet messages. Any such time zone whose
meaning is not known SHOULD be considered equivalent to "-0000"
unless there is out-of-band information confirming their meaning.
4.4. Obsolete Addressing
There are three primary differences in addressing. First, mailbox
addresses were allowed to have a route portion before the addr-spec
when enclosed in "<" and ">". The route is simply a comma-separated
list of domain names, each preceded by "@", and the list terminated
by a colon. Second, CFWS were allowed between the period-separated
elements of local-part and domain (i.e., dot-atom was not used). In
addition, local-part is allowed to contain quoted-string in addition
to just atom. Finally, mailbox-list and address-list were allowed to
have "null" members. That is, there could be two or more commas in
such a list with nothing in between them.
obs-angle-addr = [CFWS] "<" [obs-route] addr-spec ">" [CFWS]
obs-route = [CFWS] obs-domain-list ":" [CFWS]
obs-domain-list = "@" domain *(*(CFWS / "," ) [CFWS] "@" domain)
obs-local-part = word *("." word)
obs-domain = atom *("." atom)
obs-mbox-list = 1*([mailbox] [CFWS] "," [CFWS]) [mailbox]
obs-addr-list = 1*([address] [CFWS] "," [CFWS]) [address]
When interpreting addresses, the route portion SHOULD be ignored.
4.5. Obsolete header fields
Syntactically, the primary difference in the obsolete field syntax is
that it allows multiple occurrences of any of the fields and they may
occur in any order. Also, any amount of white space is allowed
before the ":" at the end of the field name.
obs-fields = *(obs-return /
obs-received /
obs-orig-date /
obs-from /
obs-sender /
obs-reply-to /
obs-to /
obs-cc /
obs-bcc /
obs-message-id /
obs-in-reply-to /
obs-references /
obs-subject /
obs-comments /
obs-keywords /
obs-resent-date /
obs-resent-from /
obs-resent-send /
obs-resent-rply /
obs-resent-to /
obs-resent-cc /
obs-resent-bcc /
obs-resent-mid /
obs-optional)
Except for destination address fields (described in section 4.5.3),
the interpretation of multiple occurrences of fields is unspecified.
Also, the interpretation of trace fields and resent fields which do
not occur in blocks prepended to the message is unspecified as well.
Unless otherwise noted in the following sections, interpretation of
other fields is identical to the interpretation of their non-obsolete
counterparts in section 3.
4.5.1. Obsolete origination date field
obs-orig-date = "Date" *WSP ":" date-time CRLF
4.5.2. Obsolete originator fields
obs-from = "From" *WSP ":" mailbox-list CRLF
obs-sender = "Sender" *WSP ":" mailbox CRLF
obs-reply-to = "Reply-To" *WSP ":" mailbox-list CRLF
4.5.3. Obsolete destination address fields
obs-to = "To" *WSP ":" address-list CRLF
obs-cc = "Cc" *WSP ":" address-list CRLF
obs-bcc = "Bcc" *WSP ":" (address-list / [CFWS]) CRLF
When multiple occurrences of destination address fields occur in a
message, they SHOULD be treated as if the address-list in the first
occurrence of the field is combined with the address lists of the
subsequent occurrences by adding a comma and concatenating.
4.5.4. Obsolete identification fields
The obsolete "In-Reply-To:" and "References:" fields differ from the
current syntax in that they allow phrase (words or quoted strings) to
appear. The obsolete forms of the left and right sides of msg-id
allow interspersed CFWS, making them syntactically identical to
local-part and domain respectively.
obs-message-id = "Message-ID" *WSP ":" msg-id CRLF
obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF
obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF
obs-id-left = local-part
obs-id-right = domain
For purposes of interpretation, the phrases in the "In-Reply-To:" and
"References:" fields are ignored.
Semantically, none of the optional CFWS surrounding the local-part
and the domain are part of the obs-id-left and obs-id-right
respectively.
4.5.5. Obsolete informational fields
obs-subject = "Subject" *WSP ":" unstructured CRLF
obs-comments = "Comments" *WSP ":" unstructured CRLF
obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF
4.5.6. Obsolete resent fields
The obsolete syntax adds a "Resent-Reply-To:" field, which consists
of the field name, the optional comments and folding white space, the
colon, and a comma separated list of addresses.
obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF
obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF
obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF
obs-resent-to = "Resent-To" *WSP ":" address-list CRLF
obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF
obs-resent-bcc = "Resent-Bcc" *WSP ":"
(address-list / [CFWS]) CRLF
obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF
obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF
As with other resent fields, the "Resent-Reply-To:" field is to be
treated as trace information only.
4.5.7. Obsolete trace fields
The obs-return and obs-received are again given here as template
definitions, just as return and received are in section 3. Their
full syntax is given in [RFC2821].
obs-return = "Return-Path" *WSP ":" path CRLF
obs-received = "Received" *WSP ":" name-val-list CRLF
obs-path = obs-angle-addr
4.5.8. Obsolete optional fields
obs-optional = field-name *WSP ":" unstructured CRLF
5. Security Considerations
Care needs to be taken when displaying messages on a terminal or
terminal emulator. Powerful terminals may act on escape sequences
and other combinations of ASCII control characters with a variety of
consequences. They can remap the keyboard or permit other
modifications to the terminal which could lead to denial of service
or even damaged data. They can trigger (sometimes programmable)
answerback messages which can allow a message to cause commands to be
issued on the recipient's behalf. They can also effect the operation
of terminal attached devices such as printers. Message viewers may
wish to strip potentially dangerous terminal escape sequences from
the message prior to display. However, other escape sequences appear
in messages for useful purposes (cf. [RFC2045, RFC2046, RFC2047,
RFC2048, RFC2049, ISO2022]) and therefore should not be stripped
indiscriminately.
Transmission of non-text objects in messages raises additional
security issues. These issues are discussed in [RFC2045, RFC2046,
RFC2047, RFC2048, RFC2049].
Many implementations use the "Bcc:" (blind carbon copy) field
described in section 3.6.3 to facilitate sending messages to
recipients without revealing the addresses of one or more of the
addressees to the other recipients. Mishandling this use of "Bcc:"
has implications for confidential information that might be revealed,
which could eventually lead to security problems through knowledge of
even the existence of a particular mail address. For example, if
using the first method described in section 3.6.3, where the "Bcc:"
line is removed from the message, blind recipients have no explicit
indication that they have been sent a blind copy, except insofar as
their address does not appear in the message header. Because of
this, one of the blind addressees could potentially send a reply to
all of the shown recipients and accidentally reveal that the message
went to the blind recipient. When the second method from section
3.6.3 is used, the blind recipient's address appears in the "Bcc:"
field of a separate copy of the message. If the "Bcc:" field sent
contains all of the blind addressees, all of the "Bcc:" recipients
will be seen by each "Bcc:" recipient. Even if a separate message is
sent to each "Bcc:" recipient with only the individual's address,
implementations still need to be careful to process replies to the
message as per section 3.6.3 so as not to accidentally reveal the
blind recipient to other recipients.
These syntactic elements are used elsewhere in the obsolete syntax or
in the main syntax. The obs-char and obs-qp elements each add ASCII
value 0. Bare CR and bare LF are added to obs-text and obs-utext.
The period character is added to obs-phrase. The obs-phrase-list
provides for "empty" elements in a comma-separated list of phrases.
Note: The "period" (or "full stop") character (".") in obs-phrase is
not a form that was allowed in earlier versions of this or any other
standard. Period (nor any other character from specials) was not
allowed in phrase because it introduced a parsing difficulty
distinguishing between phrases and portions of an addr-spec (see
section 4.4). It appears here because the period character is
currently used in many messages in the display-name portion of
addresses, especially for initials in names, and therefore must be
interpreted properly. In the future, period may appear in the
regular syntax of phrase.
obs-qp = "\" (%d0-127)
obs-text = *LF *CR *(obs-char *LF *CR)
obs-char = %d0-9 / %d11 / ; %d0-127 except CR and
%d12 / %d14-127 ; LF
obs-utext = obs-text
obs-phrase = word *(word / "." / CFWS)
obs-phrase-list = phrase / 1*([phrase] [CFWS] "," [CFWS]) [phrase]
Bare CR and bare LF appear in messages with two different meanings.
In many cases, bare CR or bare LF are used improperly instead of CRLF
to indicate line separators. In other cases, bare CR and bare LF are
used simply as ASCII control characters with their traditional ASCII
meanings.
4.2. Obsolete folding white space
In the obsolete syntax, any amount of folding white space MAY be
inserted where the obs-FWS rule is allowed. This creates the
possibility of having two consecutive "folds" in a line, and
therefore the possibility that a line which makes up a folded header
field could be composed entirely of white space.
obs-FWS = 1*WSP *(CRLF 1*WSP)
4.3. Obsolete Date and Time
The syntax for the obsolete date format allows a 2 digit year in the
date field and allows for a list of alphabetic time zone
specifications that were used in earlier versions of this standard.
It also permits comments and folding white space between many of the
tokens.
obs-day-of-week = [CFWS] day-name [CFWS]
obs-year = [CFWS] 2*DIGIT [CFWS]
obs-month = CFWS month-name CFWS
obs-day = [CFWS] 1*2DIGIT [CFWS]
obs-hour = [CFWS] 2DIGIT [CFWS]
obs-minute = [CFWS] 2DIGIT [CFWS]
obs-second = [CFWS] 2DIGIT [CFWS]
obs-zone = "UT" / "GMT" / ; Universal Time
; North American UT
; offsets
"EST" / "EDT" / ; Eastern: - 5/ - 4
"CST" / "CDT" / ; Central: - 6/ - 5
"MST" / "MDT" / ; Mountain: - 7/ - 6
"PST" / "PDT" / ; Pacific: - 8/ - 7
%d65-73 / ; Military zones - "A"
%d75-90 / ; through "I" and "K"
%d97-105 / ; through "Z", both
%d107-122 ; upper and lower case
Where a two or three digit year occurs in a date, the year is to be
interpreted as follows: If a two digit year is encountered whose
value is between 00 and 49, the year is interpreted by adding 2000,
ending up with a value between 2000 and 2049. If a two digit year is
encountered with a value between 50 and 99, or any three digit year
is encountered, the year is interpreted by adding 1900.
In the obsolete time zone, "UT" and "GMT" are indications of
"Universal Time" and "Greenwich Mean Time" respectively and are both
semantically identical to "+0000".
The remaining three character zones are the US time zones. The first
letter, "E", "C", "M", or "P" stands for "Eastern", "Central",
"Mountain" and "Pacific". The second letter is either "S" for
"Standard" time, or "D" for "Daylight" (or summer) time. Their
interpretations are as follows:
EDT is semantically equivalent to -0400
EST is semantically equivalent to -0500
CDT is semantically equivalent to -0500
CST is semantically equivalent to -0600
MDT is semantically equivalent to -0600
MST is semantically equivalent to -0700
PDT is semantically equivalent to -0700
PST is semantically equivalent to -0800
The 1 character military time zones were defined in a non-standard
way in [RFC822] and are therefore unpredictable in their meaning.
The original definitions of the military zones "A" through "I" are
equivalent to "+0100" through "+0900" respectively; "K", "L", and "M"
are equivalent to "+1000", "+1100", and "+1200" respectively; "N"
through "Y" are equivalent to "-0100" through "-1200" respectively;
and "Z" is equivalent to "+0000". However, because of the error in
[RFC822], they SHOULD all be considered equivalent to "-0000" unless
there is out-of-band information confirming their meaning.
Other multi-character (usually between 3 and 5) alphabetic time zones
have been used in Internet messages. Any such time zone whose
meaning is not known SHOULD be considered equivalent to "-0000"
unless there is out-of-band information confirming their meaning.
4.4. Obsolete Addressing
There are three primary differences in addressing. First, mailbox
addresses were allowed to have a route portion before the addr-spec
when enclosed in "<" and ">". The route is simply a comma-separated
list of domain names, each preceded by "@", and the list terminated
by a colon. Second, CFWS were allowed between the period-separated
elements of local-part and domain (i.e., dot-atom was not used). In
addition, local-part is allowed to contain quoted-string in addition
to just atom. Finally, mailbox-list and address-list were allowed to
have "null" members. That is, there could be two or more commas in
such a list with nothing in between them.
obs-angle-addr = [CFWS] "<" [obs-route] addr-spec ">" [CFWS]
obs-route = [CFWS] obs-domain-list ":" [CFWS]
obs-domain-list = "@" domain *(*(CFWS / "," ) [CFWS] "@" domain)
obs-local-part = word *("." word)
obs-domain = atom *("." atom)
obs-mbox-list = 1*([mailbox] [CFWS] "," [CFWS]) [mailbox]
obs-addr-list = 1*([address] [CFWS] "," [CFWS]) [address]
When interpreting addresses, the route portion SHOULD be ignored.
4.5. Obsolete header fields
Syntactically, the primary difference in the obsolete field syntax is
that it allows multiple occurrences of any of the fields and they may
occur in any order. Also, any amount of white space is allowed
before the ":" at the end of the field name.
obs-fields = *(obs-return /
obs-received /
obs-orig-date /
obs-from /
obs-sender /
obs-reply-to /
obs-to /
obs-cc /
obs-bcc /
obs-message-id /
obs-in-reply-to /
obs-references /
obs-subject /
obs-comments /
obs-keywords /
obs-resent-date /
obs-resent-from /
obs-resent-send /
obs-resent-rply /
obs-resent-to /
obs-resent-cc /
obs-resent-bcc /
obs-resent-mid /
obs-optional)
Except for destination address fields (described in section 4.5.3),
the interpretation of multiple occurrences of fields is unspecified.
Also, the interpretation of trace fields and resent fields which do
not occur in blocks prepended to the message is unspecified as well.
Unless otherwise noted in the following sections, interpretation of
other fields is identical to the interpretation of their non-obsolete
counterparts in section 3.
4.5.1. Obsolete origination date field
obs-orig-date = "Date" *WSP ":" date-time CRLF
4.5.2. Obsolete originator fields
obs-from = "From" *WSP ":" mailbox-list CRLF
obs-sender = "Sender" *WSP ":" mailbox CRLF
obs-reply-to = "Reply-To" *WSP ":" mailbox-list CRLF
4.5.3. Obsolete destination address fields
obs-to = "To" *WSP ":" address-list CRLF
obs-cc = "Cc" *WSP ":" address-list CRLF
obs-bcc = "Bcc" *WSP ":" (address-list / [CFWS]) CRLF
When multiple occurrences of destination address fields occur in a
message, they SHOULD be treated as if the address-list in the first
occurrence of the field is combined with the address lists of the
subsequent occurrences by adding a comma and concatenating.
4.5.4. Obsolete identification fields
The obsolete "In-Reply-To:" and "References:" fields differ from the
current syntax in that they allow phrase (words or quoted strings) to
appear. The obsolete forms of the left and right sides of msg-id
allow interspersed CFWS, making them syntactically identical to
local-part and domain respectively.
obs-message-id = "Message-ID" *WSP ":" msg-id CRLF
obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF
obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF
obs-id-left = local-part
obs-id-right = domain
For purposes of interpretation, the phrases in the "In-Reply-To:" and
"References:" fields are ignored.
Semantically, none of the optional CFWS surrounding the local-part
and the domain are part of the obs-id-left and obs-id-right
respectively.
4.5.5. Obsolete informational fields
obs-subject = "Subject" *WSP ":" unstructured CRLF
obs-comments = "Comments" *WSP ":" unstructured CRLF
obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF
4.5.6. Obsolete resent fields
The obsolete syntax adds a "Resent-Reply-To:" field, which consists
of the field name, the optional comments and folding white space, the
colon, and a comma separated list of addresses.
obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF
obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF
obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF
obs-resent-to = "Resent-To" *WSP ":" address-list CRLF
obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF
obs-resent-bcc = "Resent-Bcc" *WSP ":"
(address-list / [CFWS]) CRLF
obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF
obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF
As with other resent fields, the "Resent-Reply-To:" field is to be
treated as trace information only.
4.5.7. Obsolete trace fields
The obs-return and obs-received are again given here as template
definitions, just as return and received are in section 3. Their
full syntax is given in [RFC2821].
obs-return = "Return-Path" *WSP ":" path CRLF
obs-received = "Received" *WSP ":" name-val-list CRLF
obs-path = obs-angle-addr
4.5.8. Obsolete optional fields
obs-optional = field-name *WSP ":" unstructured CRLF
5. Security Considerations
Care needs to be taken when displaying messages on a terminal or
terminal emulator. Powerful terminals may act on escape sequences
and other combinations of ASCII control characters with a variety of
consequences. They can remap the keyboard or permit other
modifications to the terminal which could lead to denial of service
or even damaged data. They can trigger (sometimes programmable)
answerback messages which can allow a message to cause commands to be
issued on the recipient's behalf. They can also effect the operation
of terminal attached devices such as printers. Message viewers may
wish to strip potentially dangerous terminal escape sequences from
the message prior to display. However, other escape sequences appear
in messages for useful purposes (cf. [RFC2045, RFC2046, RFC2047,
RFC2048, RFC2049, ISO2022]) and therefore should not be stripped
indiscriminately.
Transmission of non-text objects in messages raises additional
security issues. These issues are discussed in [RFC2045, RFC2046,
RFC2047, RFC2048, RFC2049].
Many implementations use the "Bcc:" (blind carbon copy) field
described in section 3.6.3 to facilitate sending messages to
recipients without revealing the addresses of one or more of the
addressees to the other recipients. Mishandling this use of "Bcc:"
has implications for confidential information that might be revealed,
which could eventually lead to security problems through knowledge of
even the existence of a particular mail address. For example, if
using the first method described in section 3.6.3, where the "Bcc:"
line is removed from the message, blind recipients have no explicit
indication that they have been sent a blind copy, except insofar as
their address does not appear in the message header. Because of
this, one of the blind addressees could potentially send a reply to
all of the shown recipients and accidentally reveal that the message
went to the blind recipient. When the second method from section
3.6.3 is used, the blind recipient's address appears in the "Bcc:"
field of a separate copy of the message. If the "Bcc:" field sent
contains all of the blind addressees, all of the "Bcc:" recipients
will be seen by each "Bcc:" recipient. Even if a separate message is
sent to each "Bcc:" recipient with only the individual's address,
implementations still need to be careful to process replies to the
message as per section 3.6.3 so as not to accidentally reveal the
blind recipient to other recipients.
lunes, 18 de mayo de 2009
Autonegociación tarjetas de red
sitio en : http://sites.google.com/site/jmpproyecto/hardware/ethernet-red/protocolos-cables-y-otras-cosas
http://en.wikipedia.org/wiki/NWay
http://www.iol.unh.edu/services/testing/ge/training/1000BASE-T/ANEG_brief.php
Que es la Auto-Negotiation?
Auto-Negociación es el proceso desarrollado por el IEEE para permitir que dispositivos con diferentes tecnologías se comuniquen información entre si para conseguir inter-operar entre ellos.
La Auto-Negotiación está definida en la sección 28 of the IEEE 802.3 standard. The technologies currently supported by auto-negotiation are: 10BASE-T Half Duplex, 10BASE-T Full Duplex, 100BASE-TX Half Duplex, 100BASE-TX Full Duplex, 100BASE-T4, 100BASE-T2 Half Duplex, 100BASE-T2 Full Duplex, 1000BASE-T Half Duplex, 1000BASE-T Full Duplex, and 10GBASE-T.
FLP Bursts
The basis for all of Auto-Negotiation's functionality is the Fast Link Pulse (FLP) burst. An FLP burst is simply a sequence of 10BASE-T Normal Link Pulses (NLPs, also known as Link Test Pulses in 10Base-T world) that come together to form a message, or "word." Each FLP is composed of 33 pulse positions, with the 17 odd numbered positions corresponding to clock pulses and the 16 even numbered positions corresponding to data pulses. The time between pulse positions is 62.5µs +/- 7µs, and therefore 125µs +/- 14µs between each clock pulse.
All clock positions are required to contain a link pulse. However, data positions are not. If there is a link pulse present in a data position, it is representative of a logic one, whereas the lack of a link pulse is representative of a logic zero.
The amount of time between FLP bursts is 16ms +/- 8ms (8ms to 8.5ms for 10GBASE-T exchange), which corresponds to the time between consecutive link test pulses produced by a 10BASE-T device. This was done to allow a fixed speed 10BASE-T device to see FLP bursts and remain in the LINK TEST PASS state. For 10GBASE-T it was shortened to 8ms to 8.5ms in an effort to speed up the exchange of data.
Link Code Words (Base Pages)
The 16 data positions in an FLP burst come together to form one 16 bit word. The most important message sent in auto-negotiation is a device's Link Code Word (or Base Page). The breakdown of the bit positions in the link code word is shown in Figure 1:
Figure 1: Link Code Word
Selector Field: The first five bits of the link code word comprise the Selector Field. The Selector Field contains one of 32 possible combinations, only 2 of which are allowed to be sent, which follow:
1 0 0 0 0 = IEEE 802.3
0 1 0 0 0 = IEEE 802.9
The other 30 combinations are reserved for later use by the IEEE and should not be transmitted.
Technology Ability Field: The next 7 bits make up the Technology Ability Field. This is where a device advertises its abilities. The seven bits in this field represent the following technologies:
Bit Technology
A0 10BASE-T
A1 10BASE-T Full Duplex
A2 100BASE-TX
A3 100BASE-TX Full Duplex
A4 100BASE-T4
A5 PAUSE operation for full duplex links
A6 Asymmetric PAUSE operation for full duplex Links
A logic one in any of these positions symbolizes that the device holds that technology. The device should advertise only the technologies that it supports.
Extended Next Page: This bit is set when a station wishes to participate in an Extended Next Page Exchange. This function will be discussed in further detail later
Remote Fault: This bit can be set to inform a station that a remote fault has occurred.
Acknowledge: This bit is set to confirm the receipt of at least 3 complete, consecutive and consistent FLP bursts from a station. This functionality will be discussed in detail later.
Next Page: This bit is set when a station wishes to participate in a Next Page exchange, a concept to be discussed later.
Figure 2: Sample Link Code Word
Priority Resolution Function
Once a device is aware of its link partner's abilities, it must decide what type of link to establish. In order to ensure that all devices will choose the same Highest Common Denominator (HCD) technology, they must implement the Priority Resolution Function. This function simply ranks the possible technologies and requires a device to choose the highest one supported. The ranking is as follows:
10GBASE-T Full Duplex
1000BASE-T Full Duplex
1000BASE-T
100BASE-T2 Full Duplex
100BASE-TX Full Duplex
100BASE-T2
100BASE-T4
100BASE-TX
10BASE-T Full Duplex
10BASE-T
The Process
Now that you have all the pieces, it's time to assemble the puzzle. Here is the process by which a successful negotiation should take place:
The two link partners transmit their FLP bursts containing their link code words without the Acknowledge bit set.
The stations identify one another as auto-negotiation able within 6 to 17 (inclusive) pulses of the first received FLP burst.
Following auto-negotiation able identification, the station waits for the reception of at least 3 complete, consecutive and consistent FLP bursts (ignoring the acknowledge bit of the FLPs), the stations enter the Acknowledge Detect state, and begin transmitting FLP bursts containing their link code word with the Acknowledge bit set.
After reception of 3 more complete, consecutive and consistent FLP bursts containing a set Acknowledge bit, the stations enter the Complete Acknowledge state, and transmit 6 to 8 (inclusive) more FLP bursts containing their link code words with the Acknowledge bit set.
After transmitting the 6 to 8 (inclusive) more FLP bursts the stations will participate in Next Page or Extended Next Page exchange, if either is selected.
Upon completion of the optional Next Page or Extended Next Page exchange, the stations should resolve a HCD technology and negotiate to that link, if supported. If no common technologies are shared, no link is established.
Parallel Detection Function
The Parallel Detection Function is an auto-negotiating device's means to establish links with non-negotiating, fixed speed devices. If an auto-negotiating device receives either 10BASE-T or T4 Link Test Pulses or the idle stream of a TX device, it should do one of two things: either enable that PMA if it supports it, or refuse to establish a link. No FLPs necessary. A device can never parallel detect to a full duplex link, however. Also because 1000BASE-T, 100BASE-T2, and 10GBASE-T have a Master/Slave configuration, parallel detection of these abilities are not allowed.
Next Page Function
An optional additional feature to the auto-negotiation capability is the Next Page function. Next Pages are a means by which devices can transmit additional information beyond their link code words. Some common uses for a device to use Next Page exchanges are to advertise the abilities of 1000BASE-T, and 100ASE-T2. A Next Page exchange occurs immediately after the Base Page Exchange. If both stations advertise the Next Page ability, then they are required to transmit at least one Next Page each. There are four types of Next Pages: Message pages, Unformatted pages, extended Message Pages, and extended Unformatted Pages. The encoding for the Message Page and Unformatted Message page is shown in Figure 3 and Figure 4. The encoding and description of the extended Message Page and extended Unformatted Message Page will be defined later on.
Figure 3: Message Page Encoding
Figure 4: Unformatted Page Encoding
Message Code Field: This is an 11-bit wide field that can contain one of 2048 possible Message Codes. However, all but 9 are reserved for future use by the IEEE which can be seen in Table 28C-1.
Unformatted Code Field: This is an 11-bit wide field whose contents vary. Unformatted Pages are preceded by a Message Page that defines what information is to be carried in their code field.
Toggle (T): This bit simply "toggles" between logic one and zero in consecutive Next Pages. It's purpose is to give a station assurance that it is receiving Next Pages in the proper order and has not missed any. The initial value of the Toggle bit is the opposite of bit 11 in the station's Link Code Word.
Acknowledge 2 (Ack2): This bit simply tells a station's link partner whether or not it is able to comply with a message. This bit is set to logic one if a station can comply with a message or zero if it can't. It should be noted that this bit is rarely, if ever used.
Message Page (MP): This bit is used to differentiate between the two types of Next Pages: a logic zero indicates that it is an Unformatted Page, where a logic one indicates a Message Page.
Acknowledge (Ack): This bit is set to indicate that a device has recieved its Link Partner's Link Codeword.
Next Page (NP): This bit simply indicates whether or not there are more Next Pages to come. When set to logic one, it indicates that additional pages will follow, whereas a logic zero indicates that there are no remaining pages.
The Next Page exchange concludes once both stations have set their Next Page bits to zero.
A typical Next Page Exchange to establish a 1000BASE-T Full or Half duplex link can be seen in figure 5.
Extended Next Page Function
Another optional additional feature to the auto-negotiation capability is the Extended Next Page function. Extended Next Pages are an extension of the Next Page fuction which was described earlier. When both devices advertise Next Page and Extended Next Page abilities they will then use Extended Message Pages and Extended Unformatted Message Pages to transmit additional information beyond their link code words. Extended Next Pages are similar to a regular Next Page except that they are 48-bit pages and not 16. The encoding for the Extended Message Page and Extended Unformatted Message Page is shown in Figures 28-13 and 28-14.
Message Code Field: This is an 11-bit wide field that can contain one of 2048 possible Message Codes which we have defined earlier in the Next Page Exchange process and can be seen in table 28C-1.
Toggle (T): This bit simply "toggles" between logic one and zero in consecutive Next Pages. It's purpose is to give a station assurance that it is receiving Next Pages in the proper order and has not missed any. The initial value of the Toggle bit is the opposite of bit 11 in the station's Link Code Word.
Acknowledge 2 (Ack2): This bit simply tells a station's link partner whether or not it is able to comply with a message. This bit is set to logic one if a station can comply with a message or zero if it can't. It should be noted that this bit is rarely, if ever used.
Message Page (MP): This bit is used to differentiate between the two types of Next Pages: a logic zero indicates that it is an Unformatted Page, where a logic one indicates a Message Page.
Acknowledge (Ack): This bit is set to indicate that a device has recieved its Link Partner's Link Codeword.
Next Page (NP): This bit simply indicates whether or not there are more Next Pages to come. When set to logic one, it indicates that additional pages will follow, whereas a logic zero indicates that there are no remaining pages.
Extended Unformatted Code Field: This is a 32-bit or 43-bit wide field, which may contain arbitrary value depending on the preceding Message Code. This field is 32-bits wide in an Extended Message Page and 43-bits wide in an Extended Unformatted Page.
The Extended Next Page exchange concludes once both stations have transmitted all the information that they wish and both have begun to transmit Null Message Codes.
A typical Extended Next Page Exchange to establish a 10GBase-T link can be seen in figure 6. (This Figure does not illustrate that the Extended Next Page is 48 bits long)
http://en.wikipedia.org/wiki/NWay
http://www.iol.unh.edu/services/testing/ge/training/1000BASE-T/ANEG_brief.php
Que es la Auto-Negotiation?
Auto-Negociación es el proceso desarrollado por el IEEE para permitir que dispositivos con diferentes tecnologías se comuniquen información entre si para conseguir inter-operar entre ellos.
La Auto-Negotiación está definida en la sección 28 of the IEEE 802.3 standard. The technologies currently supported by auto-negotiation are: 10BASE-T Half Duplex, 10BASE-T Full Duplex, 100BASE-TX Half Duplex, 100BASE-TX Full Duplex, 100BASE-T4, 100BASE-T2 Half Duplex, 100BASE-T2 Full Duplex, 1000BASE-T Half Duplex, 1000BASE-T Full Duplex, and 10GBASE-T.
FLP Bursts
The basis for all of Auto-Negotiation's functionality is the Fast Link Pulse (FLP) burst. An FLP burst is simply a sequence of 10BASE-T Normal Link Pulses (NLPs, also known as Link Test Pulses in 10Base-T world) that come together to form a message, or "word." Each FLP is composed of 33 pulse positions, with the 17 odd numbered positions corresponding to clock pulses and the 16 even numbered positions corresponding to data pulses. The time between pulse positions is 62.5µs +/- 7µs, and therefore 125µs +/- 14µs between each clock pulse.
All clock positions are required to contain a link pulse. However, data positions are not. If there is a link pulse present in a data position, it is representative of a logic one, whereas the lack of a link pulse is representative of a logic zero.
The amount of time between FLP bursts is 16ms +/- 8ms (8ms to 8.5ms for 10GBASE-T exchange), which corresponds to the time between consecutive link test pulses produced by a 10BASE-T device. This was done to allow a fixed speed 10BASE-T device to see FLP bursts and remain in the LINK TEST PASS state. For 10GBASE-T it was shortened to 8ms to 8.5ms in an effort to speed up the exchange of data.
Link Code Words (Base Pages)
The 16 data positions in an FLP burst come together to form one 16 bit word. The most important message sent in auto-negotiation is a device's Link Code Word (or Base Page). The breakdown of the bit positions in the link code word is shown in Figure 1:
Figure 1: Link Code Word
Selector Field: The first five bits of the link code word comprise the Selector Field. The Selector Field contains one of 32 possible combinations, only 2 of which are allowed to be sent, which follow:
1 0 0 0 0 = IEEE 802.3
0 1 0 0 0 = IEEE 802.9
The other 30 combinations are reserved for later use by the IEEE and should not be transmitted.
Technology Ability Field: The next 7 bits make up the Technology Ability Field. This is where a device advertises its abilities. The seven bits in this field represent the following technologies:
Bit Technology
A0 10BASE-T
A1 10BASE-T Full Duplex
A2 100BASE-TX
A3 100BASE-TX Full Duplex
A4 100BASE-T4
A5 PAUSE operation for full duplex links
A6 Asymmetric PAUSE operation for full duplex Links
A logic one in any of these positions symbolizes that the device holds that technology. The device should advertise only the technologies that it supports.
Extended Next Page: This bit is set when a station wishes to participate in an Extended Next Page Exchange. This function will be discussed in further detail later
Remote Fault: This bit can be set to inform a station that a remote fault has occurred.
Acknowledge: This bit is set to confirm the receipt of at least 3 complete, consecutive and consistent FLP bursts from a station. This functionality will be discussed in detail later.
Next Page: This bit is set when a station wishes to participate in a Next Page exchange, a concept to be discussed later.
Figure 2: Sample Link Code Word
Priority Resolution Function
Once a device is aware of its link partner's abilities, it must decide what type of link to establish. In order to ensure that all devices will choose the same Highest Common Denominator (HCD) technology, they must implement the Priority Resolution Function. This function simply ranks the possible technologies and requires a device to choose the highest one supported. The ranking is as follows:
10GBASE-T Full Duplex
1000BASE-T Full Duplex
1000BASE-T
100BASE-T2 Full Duplex
100BASE-TX Full Duplex
100BASE-T2
100BASE-T4
100BASE-TX
10BASE-T Full Duplex
10BASE-T
The Process
Now that you have all the pieces, it's time to assemble the puzzle. Here is the process by which a successful negotiation should take place:
The two link partners transmit their FLP bursts containing their link code words without the Acknowledge bit set.
The stations identify one another as auto-negotiation able within 6 to 17 (inclusive) pulses of the first received FLP burst.
Following auto-negotiation able identification, the station waits for the reception of at least 3 complete, consecutive and consistent FLP bursts (ignoring the acknowledge bit of the FLPs), the stations enter the Acknowledge Detect state, and begin transmitting FLP bursts containing their link code word with the Acknowledge bit set.
After reception of 3 more complete, consecutive and consistent FLP bursts containing a set Acknowledge bit, the stations enter the Complete Acknowledge state, and transmit 6 to 8 (inclusive) more FLP bursts containing their link code words with the Acknowledge bit set.
After transmitting the 6 to 8 (inclusive) more FLP bursts the stations will participate in Next Page or Extended Next Page exchange, if either is selected.
Upon completion of the optional Next Page or Extended Next Page exchange, the stations should resolve a HCD technology and negotiate to that link, if supported. If no common technologies are shared, no link is established.
Parallel Detection Function
The Parallel Detection Function is an auto-negotiating device's means to establish links with non-negotiating, fixed speed devices. If an auto-negotiating device receives either 10BASE-T or T4 Link Test Pulses or the idle stream of a TX device, it should do one of two things: either enable that PMA if it supports it, or refuse to establish a link. No FLPs necessary. A device can never parallel detect to a full duplex link, however. Also because 1000BASE-T, 100BASE-T2, and 10GBASE-T have a Master/Slave configuration, parallel detection of these abilities are not allowed.
Next Page Function
An optional additional feature to the auto-negotiation capability is the Next Page function. Next Pages are a means by which devices can transmit additional information beyond their link code words. Some common uses for a device to use Next Page exchanges are to advertise the abilities of 1000BASE-T, and 100ASE-T2. A Next Page exchange occurs immediately after the Base Page Exchange. If both stations advertise the Next Page ability, then they are required to transmit at least one Next Page each. There are four types of Next Pages: Message pages, Unformatted pages, extended Message Pages, and extended Unformatted Pages. The encoding for the Message Page and Unformatted Message page is shown in Figure 3 and Figure 4. The encoding and description of the extended Message Page and extended Unformatted Message Page will be defined later on.
Figure 3: Message Page Encoding
Figure 4: Unformatted Page Encoding
Message Code Field: This is an 11-bit wide field that can contain one of 2048 possible Message Codes. However, all but 9 are reserved for future use by the IEEE which can be seen in Table 28C-1.
Unformatted Code Field: This is an 11-bit wide field whose contents vary. Unformatted Pages are preceded by a Message Page that defines what information is to be carried in their code field.
Toggle (T): This bit simply "toggles" between logic one and zero in consecutive Next Pages. It's purpose is to give a station assurance that it is receiving Next Pages in the proper order and has not missed any. The initial value of the Toggle bit is the opposite of bit 11 in the station's Link Code Word.
Acknowledge 2 (Ack2): This bit simply tells a station's link partner whether or not it is able to comply with a message. This bit is set to logic one if a station can comply with a message or zero if it can't. It should be noted that this bit is rarely, if ever used.
Message Page (MP): This bit is used to differentiate between the two types of Next Pages: a logic zero indicates that it is an Unformatted Page, where a logic one indicates a Message Page.
Acknowledge (Ack): This bit is set to indicate that a device has recieved its Link Partner's Link Codeword.
Next Page (NP): This bit simply indicates whether or not there are more Next Pages to come. When set to logic one, it indicates that additional pages will follow, whereas a logic zero indicates that there are no remaining pages.
The Next Page exchange concludes once both stations have set their Next Page bits to zero.
A typical Next Page Exchange to establish a 1000BASE-T Full or Half duplex link can be seen in figure 5.
Extended Next Page Function
Another optional additional feature to the auto-negotiation capability is the Extended Next Page function. Extended Next Pages are an extension of the Next Page fuction which was described earlier. When both devices advertise Next Page and Extended Next Page abilities they will then use Extended Message Pages and Extended Unformatted Message Pages to transmit additional information beyond their link code words. Extended Next Pages are similar to a regular Next Page except that they are 48-bit pages and not 16. The encoding for the Extended Message Page and Extended Unformatted Message Page is shown in Figures 28-13 and 28-14.
Message Code Field: This is an 11-bit wide field that can contain one of 2048 possible Message Codes which we have defined earlier in the Next Page Exchange process and can be seen in table 28C-1.
Toggle (T): This bit simply "toggles" between logic one and zero in consecutive Next Pages. It's purpose is to give a station assurance that it is receiving Next Pages in the proper order and has not missed any. The initial value of the Toggle bit is the opposite of bit 11 in the station's Link Code Word.
Acknowledge 2 (Ack2): This bit simply tells a station's link partner whether or not it is able to comply with a message. This bit is set to logic one if a station can comply with a message or zero if it can't. It should be noted that this bit is rarely, if ever used.
Message Page (MP): This bit is used to differentiate between the two types of Next Pages: a logic zero indicates that it is an Unformatted Page, where a logic one indicates a Message Page.
Acknowledge (Ack): This bit is set to indicate that a device has recieved its Link Partner's Link Codeword.
Next Page (NP): This bit simply indicates whether or not there are more Next Pages to come. When set to logic one, it indicates that additional pages will follow, whereas a logic zero indicates that there are no remaining pages.
Extended Unformatted Code Field: This is a 32-bit or 43-bit wide field, which may contain arbitrary value depending on the preceding Message Code. This field is 32-bits wide in an Extended Message Page and 43-bits wide in an Extended Unformatted Page.
The Extended Next Page exchange concludes once both stations have transmitted all the information that they wish and both have begun to transmit Null Message Codes.
A typical Extended Next Page Exchange to establish a 10GBase-T link can be seen in figure 6. (This Figure does not illustrate that the Extended Next Page is 48 bits long)
martes, 28 de octubre de 2008
teclado midi en debian.
de http://lau.linuxaudio.org/TiMidity-howto.html
1.- Instalo timidity
Sin problemas, es facil incluso si se baja uno el tarball y lo compila.
2.- Hay que instalar tambien los modulos de sonido :
freepats se llama el paquete.
Hay uno que se llama titanic que dicen que es mucho mejor. http://www.ctgmusic.com/topic.php?id=8749&page=1
3.- El teclado midi usb se enchufa y escribimos :
aconnect -i
a mi entre otras cosas me pone esto :
client 20: 'UMX 49' [type=kernel]
0 'UMX 49 MIDI 1 '
esto quiere decir que el puerto input es 20:0
4.- Ejecutamo timidity en background de esta forma :
1.- Instalo timidity
Sin problemas, es facil incluso si se baja uno el tarball y lo compila.
2.- Hay que instalar tambien los modulos de sonido :
freepats se llama el paquete.
Hay uno que se llama titanic que dicen que es mucho mejor. http://www.ctgmusic.com/topic.php?id=8749&page=1
3.- El teclado midi usb se enchufa y escribimos :
aconnect -i
a mi entre otras cosas me pone esto :
client 20: 'UMX 49' [type=kernel]
0 'UMX 49 MIDI 1 '
esto quiere decir que el puerto input es 20:0
4.- Ejecutamo timidity en background de esta forma :
$timidity -iA -B2,8 -Os -EFreverb=0
5.- Buscamos los puertos midi de esta forma :
aconnect -o
client 128: 'TiMidity' [type=user]
0 'TiMidity port 0 '
1 'TiMidity port 1 '
2 'TiMidity port 2 '
3 'TiMidity port 3 '
Ya tenemos el puerto de salida 128:0
6- Juntamos los puertos con aconnect
aconnect 20:0 128:0
Ya podemos tocar.
Links :
http://www.hispasonic.com/comunidad/latencia-con-timidity-problema-posible-solucion-t225540.html
lunes, 15 de septiembre de 2008
Ordenador nuevo
de aqui : http://www.elotrolado.net/hilo_me-podeis-ayudar-con-renovacion-200_1081496
Vamos a ver como queda el presupuestillo en el día de hoy.
La placa base incluye tarjeta gráfica
Si queremos HTPC mirar este link
PC-COMPONENTES
ALTERNATE
Vamos a terminarlo en alternate :
Ventilador: Arctic-Cooling Freezer 64 Pro 16 Euros
Caja :MS-TECH LC-402 (Negro/verde, negro) 32 Euros
Fuente : OCZ StealthXStream 500W (Negro, 1x PCIe) 59 Euros
Total de terminación: 59+32+16= 107 Euros
Nos queda el ordenador : 197+107= 304 Euros
Solo faltaría el disco duro y montarlo
Vamos a ver como queda el presupuestillo en el día de hoy.
La placa base incluye tarjeta gráfica
- Integrated ATI Radeon HD3200 graphics (DirectX10)
Si queremos HTPC mirar este link
PC-COMPONENTES
| ARTÍCULO | PRECIO | |
| Placa Base | Gigabyte GA-MA78G-DS3H Socket AM2+70 | 76.00 |
| CPU | AMD Athlon64 X2 5200+ 2.6Ghz AM2 Box 67 | 89.00 |
| memoria | Corsair Twin2x2048-6400C4 2GB 2x1GB 4-4-4-12 | 47.00 |
| total | 212.00 |
ALTERNATE
| ARTÍCULO | PRECIO | |
| Placa Base | Gigabyte GA-MA78G-DS3H Socket AM2+70 | 69.00 |
| CPU | AMD Athlon64 X2 5600+ 2.6Ghz AM2 Box 67 | 84.00 |
| memoria | kingston 2GB 2x1GB 4-4-4-12 | 44.00 |
| total | 197.00 |
Vamos a terminarlo en alternate :
Ventilador: Arctic-Cooling Freezer 64 Pro 16 Euros
Caja :MS-TECH LC-402 (Negro/verde, negro) 32 EurosFuente : OCZ StealthXStream 500W (Negro, 1x PCIe) 59 Euros
Total de terminación: 59+32+16= 107 Euros
Nos queda el ordenador : 197+107= 304 Euros
Solo faltaría el disco duro y montarlo
martes, 9 de septiembre de 2008
playstation
- V15 - V16: SCPH-75004, igual que las anteriores con pequeñas modificaciones en placa.
Todos los modelos de PSTwo traen incorporado de serie el receptor infrarojo y el conector de
red (RJ45).
En la caja pone SCPH-75004 por lo que segun parece es v15 o v16
Fotos de las piezas
Todos los modelos de PSTwo traen incorporado de serie el receptor infrarojo y el conector de
red (RJ45).
En la caja pone SCPH-75004 por lo que segun parece es v15 o v16
Fotos de las piezas
martes, 12 de agosto de 2008
css posicion
Los valores de posicion en css
fuente
{
position:valor;
}
Los cuatro valores.
posicion puede tomar 4 valores : static, relative, absolute, y fixed. El defecto es static ; Para cualquier otro valor hay que aplicar la declaración CSS.
El bloque contenedor.
Para especificar la posición exacta de un elemento css, hay que indicar las propiedades : top,bottm,left y right. Estas son las coordenadas relativas al punto de referencia. Pero... ¿Cual es ese punto? eso depende de la posicion.
position: static: (defecto) No hay punto de referencia, un bloque estático no puede ser movido, su posición depende del flujo html/cssposition: relative: El punto de referencia es la posición del elemento que le toca si en el flujo html/css. Para que se entienda (o liarlo mas) , static es lo mismo que relative con coordenadas cero.position: absolute: La referencia es el bloque que lo contiene, que es el primer bloque antecesor que no sea estático. Si no existe tal bloque, el <html> sirve de contenedor (en los viejos navegadores, es el <body≶ el que hace de contenedor por defecto).position: fixed: La ventana del navegador.
static
Un elemento con position: static sigue el flujo de la pagina.No puede ser movido del flujo, y ignora las declaraciones top,bottom,left y right
relative
Un elemento con position: relative inicialmente tiene la posición del flujo normal de la página, pero luego es movido por los valores top, bottom, left, and/or right declarados. El espacio que originalmente tenía el elemento queda vacío. puesto que el flujo no se vuelve a recalcular.(comprobar).
Tiene que quedar claro que el flujo normal de la página, actua como si el elemento ocupara el lugar y posteriormente lo cambia de sitio, por lo que su sitio no es ocupado.
Al hacer esto, el elmento se pierde o pisa otros.... No suele ser interesante, pero suele usarse para servir de contenedor. como un static no puede servir de contenedor a un elemento absoluto, un truco es ponerlo relativo con coordenadas 0.
absolute
Un elemento con position: absolute es sacado fuera del norma flujo de la página y posicionado en la coordenadas relativas la bloque que lo contiene.
Como el elemento con posicion absoluta es sacado fuera del flujo normal del documento. i.e. el normal flujo del documento se comporta como si el elemento no existiera, y al final, se posiciona en el lugar indicado por left,right.....
fixed
Un elemento con position: fixed no entra en el flujo normal del documento y posicionado en las coordenadas indicadas relativas a la ventana del browser. Y permanece alli incluso si hay scroll.
Suscribirse a:
Entradas (Atom)