Esta es la página de discusión para discutir las mejoras en el artículo del Modo de transferencia asincrónica . Este no es un foro de discusión general sobre el tema del artículo. |
Políticas de artículos
|
Buscar fuentes: Google ( libros · noticias · periódicos · académico · imágenes gratuitas · referencias de WP ) · FENS · JSTOR · NYT · TWL |
Archivos : 1 , 2 |
Computación / Redes de WikiProject | (Clase C clasificada, importancia media) |
---|---|
Telecomunicaciones de WikiProject | (Clase C clasificada, importancia media) |
---|---|
P-NNI es el estado del enlace pero no necesariamente el camino más corto
El estándar P-NNI especifica el intercambio de información sobre el estado del enlace, similar a lo que hacen IS-IS y OSPF. Tiene más niveles de jerarquía y más métricas, pero el enfoque básico es similar.
Sin embargo, no especifica el algoritmo de enrutamiento, es decir, el algoritmo que elige la ruta para un destino en particular. La razón es que esto no es necesario; La configuración de SVC utiliza el enrutamiento de origen, por lo que no es necesario que los conmutadores acuerden cuál será la ruta elegida para un destino determinado. Los conmutadores sin conexión requieren un acuerdo para evitar bucles, pero la configuración ATM SVC no. Por lo tanto, la norma deja este aspecto abierto a la elección de los implementadores.
Obviamente, es de esperar que se use algún algoritmo similar al algoritmo de Dijkstra para determinar la ruta para una conexión en particular, pero no es correcto decir que el estándar "usa el mismo algoritmo de ruta más corta que usa OSPF ..." Paul Koning 17:01, 2 de mayo de 2007 (UTC)
- He hecho correcciones para aclarar esto. ~ Kvng ( charla ) 13:46, 22 de mayo de 2020 (UTC)
Admisión de llamada
El artículo dice: "Para admitir una llamada primero, se debe establecer una VPC. Esto garantizará el enrutamiento correcto de un extremo a otro". Esto es incorrecto. En la señalización para la configuración de SVC, se especifica la ruta (consulte mi comentario anterior sobre P-NNI). No requiere una VPC preexistente, para enrutamiento o para cualquier otro propósito. Se admite una llamada si el algoritmo de control de admisión decide admitir la llamada, normalmente porque los recursos que solicita la llamada (en los mensajes de señalización) están disponibles.
Un implementador de red ciertamente puede usar una VPC como troncal y enrutar una nueva SVC a través de dicha troncal si la ruta de origen lo permite, pero no hay ningún requisito para hacerlo; si una red hace eso, es un asunto interno que es invisible para el usuario. Paul Koning 17:06, 2 de mayo de 2007 (UTC)
- El texto mencionado ya no está en el artículo. Ni siquiera hay una instancia de VPC ' que aparentemente significa conexión de ruta virtual. ~ Kvng ( charla ) 14:29, 22 de mayo de 2020 (UTC)
también operan a tasas OC-192 (STM64)
- La siguiente discusión está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.
No parece haber una razón clara para la afirmación "Los conmutadores ATM también pueden funcionar a tasas OC-192 (STM64)". para ser parte de un párrafo que trata sobre ATM sobre IP y enrutamiento IP (no conmutación ATM). La relevancia de esta declaración debe ser calificada con información adicional, o si de hecho se trata de un tema no relacionado, debe incluirse en un párrafo separado y desarrollarse. Lo he quitado por el momento. - Het 02:02, 2 de octubre de 2007 (UTC)
minúsculas correcto
Dgtsyb, está confundido y confunde varios temas completamente diferentes en este razonamiento suyo: I.150 solo usa minúsculas en el título, que es simplemente el estilo de la casa de ITU-T para los títulos.
- Como puede ver en el enlace de la UIT, el modo de transferencia asincrónica también se usa en la p.2.
- Los trabajos de referencia cuidadosamente editados y las publicaciones como Britannica también usan minúsculas al explicar siglas como ATM.
- Algunas organizaciones (incluida Wikipedia) no escriben con mayúscula los sustantivos comunes en los títulos, pero nunca escriben en minúsculas los nombres propios en los títulos o en el texto. Si algo está en minúsculas en un título de la UIT, puede estar seguro de que definitivamente es un sustantivo común, y publicaciones cuidadosamente editadas como Britannica también lo hacen en minúsculas.
- No vuelva a revertir mientras se discute el problema aquí. - Espoo ( charla ) 12:53, 1 de enero de 2010 (UTC)
- La segunda página de I.150 es una lista de títulos. La página i, 1 y 11 (el cuerpo del texto) lo tiene capiltalizado en todas partes. Es un nombre propio y por eso se movió el 24 de diciembre de 2009 del modo de transferencia asincrónica al modo de transferencia asincrónica . Consideraría que ATM Theory and Applications , parte de la serie McGraw Hill Signature sobre telecomunicaciones, es un trabajo cuidadosamente editado. Lo mismo puede decirse de Integrated Services Digital Network, , banda ancha de la Red Digital de Servicios Integrados , y la red telefónica pública conmutada y muchas otras áreas temáticas en el campo de las comunicaciones, un puñado de que a partir de las modificaciones recientes que parecen desear alguna manera hacen los nombres comunes . Por ejemplo, el movimiento de la red de banda ancha digital de servicios integrados , a la red digital de servicios integrados de banda ancha es muy inadecuado: el trabajo sólo citadas en ese artículo capitaliza RDSI, RDSI-BA, así como cajeros automáticos en sus formas largas en todas partes.
- Puede que le resulte útil pensar si los cajeros automáticos (o cualquiera de estos) están correctamente precedidos por alguno o algunos . En las telecomunicaciones, nos referimos ni a cualquier cajero automático ni algunos cajeros automáticos; ni ninguna B-ISDN ni alguna B-ISDN. Donde es obvio que podemos decir cualquier red telefónica, o algún protocolo de transporte, naturalmente. Los sustantivos comunes se refieren a una clase. ATM no es una clase. Como contraejemplo, considere el código de redundancia cíclica . CRC no es un nombre propio. Es una clase de algoritmos. CRC-32c es un nombre propio. Otro ejemplo: Stream Control Transmission Protocol es un nombre propio.
- Otro ejemplo: verá que en los artículos y en I.150 sobre ATM, ATM se escribe en mayúsculas como Modo de transferencia asincrónica y, sin embargo , la conmutación por división de tiempo asincrónica no. La conmutación por división de tiempo asincrónica es un nombre común que se refiere a la clase de protocolos de los cuales ATM es una instancia estandarizada, específica y particular.
- Pareces molesto porque revoqué tus cambios. Una vez, muy a menudo, un editor recorre estas páginas cambiando todos los nombres propios a minúsculas, lo que provoca un esfuerzo por volver a cambiarlos todos. Para evitar molestias, es común simplemente revertirlos sin mucho comentario. Considere todos estos cambios como controvertidos y analice los cambios previstos antes de realizarlos para evitar causar trabajo innecesario a los colaboradores habituales de estos artículos. Considere también reducir esa carga de trabajo revirtiendo sus propios cambios recientes en estos artículos. Gracias. - Dgtsyb ( charla ) 14:12, 1 de enero de 2010 (UTC)
- I.150 no pondría en minúscula "modo de transferencia asincrónica" en ningún lugar si fuera un nombre propio. El uso de mayúsculas en las otras páginas siempre está al lado del acrónimo, como explicación, y es un (mal) hábito generalizado explicar acrónimos de sustantivos comunes usando mayúsculas. (Malo porque hace que la gente crea que estos sustantivos son nombres propios). Muchas, si no la mayoría de las páginas web de la UIT, usan minúsculas. Incluso muchas, si no la mayoría, de las páginas web de la UIT con mayúsculas lo utilizan para explicar el acrónimo (y luego los escritores / editores no profesionales, que solo están formados como ingenieros, a menudo se confunden y piensan que también deberían hacerlo en otros lugares). El mero hecho de que publicaciones cuidadosamente editadas como Britannica usen minúsculas demuestra que ATM es un sustantivo común.
- Créame, los editores profesionales de enciclopedias saben mucho más sobre gramática y ortografía que los ingenieros, y los editores profesionales de obras de referencia tienen a su disposición amplias bases de datos de citas, en las que basan sus decisiones. Cuando ven, por ejemplo, que los ingenieros usan tanto minúsculas como mayúsculas, los editores profesionales usan métodos profesionales que no están a nuestra disposición para decidir cuál es más común y los ponderan en función de si se trata de textos "importantes" bien editados destinados al público o para uso interno / colegas / otros ingenieros. Tiene razón en que algunas publicaciones técnicas (y legales) cuidadosamente editadas siguen la predilección de esas profesiones por la práctica barroca (siglo XVIII) de escribir palabras importantes en mayúsculas incluso cuando son sustantivos comunes, pero MOS claramente dice que se evite el uso innecesario de mayúsculas, en otras palabras. cuando otras fuentes confiables usan minúsculas. Cualquier intento de usar pruebas como "cualquiera" o "algunos" para decidir si algo es un sustantivo común equivale a OR y es irremediablemente amateur. Espero que esté de acuerdo en que es bastante común en inglés usar mayúsculas innecesariamente, incluso cuando no son nombres propios. Espero que también esté de acuerdo en que es mucho menos común que incluso los escritores aficionados usen nombres propios en minúsculas erróneamente. Esto quizás le ayude a darse cuenta de lo improbable que es la idea de que los editores de Britannica con su formación y su enorme base de datos de citas pusieran erróneamente en minúsculas un nombre propio.
- Esto debe interpretarse como un ataque a los editores que revierten sus versiones. Ciertamente no muestra este atributo de 'editor profesional', ya que simplemente ignora el razonamiento bien fundado que hace que los sustantivos sean apropiados o comunes en la tecnología. Kbrose ( charla ) 16:55, 1 de enero de 2010 (UTC)
- Una vez más, defiende OR como mejor que seguir el uso en fuentes confiables. Si estos usan tanto mayúsculas como minúsculas, MOS indica claramente que debemos usar minúsculas, especialmente cuando obras de referencia general como Britannica también usan minúsculas (sin mencionar la mayoría de las páginas web de ITU e IEC). Su agresiva eliminación de información es un ataque, no es que yo señale que ni siquiera se supone que debemos tratar de ser editores profesionales y definitivamente no tratar de estar por encima de ellos. (Soy un editor profesional, por cierto, pero esa no es la razón por la que debemos seguir lo que creo que es claramente correcto). - Espoo ( charla ) 17:09, 1 de enero de 2010 (UTC)
- Esto debe interpretarse como un ataque a los editores que revierten sus versiones. Ciertamente no muestra este atributo de 'editor profesional', ya que simplemente ignora el razonamiento bien fundado que hace que los sustantivos sean apropiados o comunes en la tecnología. Kbrose ( charla ) 16:55, 1 de enero de 2010 (UTC)
- Sus comentarios acerca de que algunos editores "pisotean" y otros son "regulares" indican que no ha entendido una de las ideas principales de WP y que tiene una tendencia a intentar poseer artículos. Una de las razones por las que WP es tan bueno es porque las personas que pasan mucho tiempo leyendo y escribiendo sobre un tema pueden ser ciegas a problemas importantes, incluidas las "reglas" (hábitos) de ortografía en inglés general y al uso en obras de referencia generales e incluso en sitios web especializados como IEC e ITU. Los visitantes poco frecuentes, especialmente cuando proporcionan fuentes confiables, definitivamente no deben ser simplemente ignorados, revertidos y expulsados. Es una idea especialmente mala eliminar información de buena fuente. No me hubiera molestado tanto si hubiera cambiado mis ediciones en lugar de simplemente revertirlas todas y, por lo tanto, eliminar la información que ITU, IEC, Wired Magazine y Britannica usan en minúsculas. - Espoo ( conversación ) 15:57, 1 de enero de 2010 (UTC)
Es bastante obvio que User: Dgtsyb no está confundido acerca de estos temas, ya que el editor acaba de exponer de manera explícita y correcta las muy buenas razones que se utilizan para establecer el uso correcto y común de los nombres no solo en las telecomunicaciones, sino también en el idioma inglés. Las explicaciones del editor también tienen peso sobre la base de sus contribuciones sustanciales y bien informadas a muchos de estos artículos. No seguir estos criterios es absurdo y sería controvertido, sin importar lo que pudiera usar algún texto de referencia. Cabe señalar que muchas publicaciones, por ejemplo, tampoco capitalizan incorrectamente Internet por algún principio, pero seguimos insistiendo en el uso adecuado de WP. El uso de mayúsculas en los títulos de ATM e ISDN completamente detallados es muy notable y está en línea con todo nuestro uso de nombres propios en WP. Kbrose ( charla ) 16:06, 1 de enero de 2010 (UTC)
- Con su comentario ridículo " no importa lo que pueda usar algún texto de referencia ", simplemente se descalificó sin darse cuenta y puso sus reversiones agresivas bajo una luz aún peor porque la política de WP es muy clara en que las ediciones deben basarse en fuentes confiables y específicamente fuentes de referencia generales como como Britannica y, en menor grado, sobre su uso en la literatura especializada y en absoluto sobre los análisis de ningún editor, por "sustanciales y bien informadas" que hayan sido sus contribuciones.
- Tus comentarios también son simplemente absurdos por otras razones. Puede haber razones para usar mayúsculas, pero Dgtsyb estaba claramente confundido al usar el razonamiento ilógico y erróneo " minúsculas en el título, que es simplemente el estilo de la casa del UIT-T para los títulos " . Vuelva a leer esto varias veces:
- Algunas organizaciones (incluidas la UIT y Wikipedia) no escriben en mayúsculas los sustantivos comunes en los títulos, pero nunca escriben en minúsculas los nombres propios en los títulos (o en el texto). Si algo está en minúsculas en un título de la UIT, puede estar seguro de que definitivamente es un sustantivo común '.
- Deje de eliminar información valiosa y de buenas fuentes, eso es claramente vandalismo. Si está convencido de usar mayúsculas, cámbielo, pero no elimine las fuentes confiables que muestren un uso generalizado de minúsculas por parte de organizaciones y editores distinguidos. - Espoo ( charla ) 16:34, 1 de enero de 2010 (UTC)
- Es muy interesante que solo considere * su * fuente como confiable. Cuando se documentó el uso adecuado con fuentes confiables de igual importancia, las descartó con su propia interpretación y elección de cita. Esto documenta sus intentos de poseer la versión que le gusta ver. Kbrose ( charla ) 16:40, 1 de enero de 2010 (UTC)
- En realidad, creo que los libros de texto de nivel universitario no introductorios publicados por McGraw Hill y Prentice Hall (pilares con John Wiley en textos de ingeniería), son más confiables que ITU-T, ISO / IEC y Encyclopedia Britannica. De estos, los libros de texto son, creo, fuentes secundarias ; ITU-T e ISO / IEC, fuentes primarias ; Encyclopedia Britannica, una fuente terciaria : por WP: PRIMARY . La entrada EB, como una fuente terciaria clara, no puede usarse para respaldar una posición sobre si el sustantivo es común o propio, ya que ciertamente no es el tema de la entrada EB. Las fuentes primarias no se pueden analizar para determinar una parte del discurso. Por lo tanto, parece que las conclusiones de Espoo deben considerarse investigación original . No creo que las fuentes citadas incorrectamente eliminadas puedan considerarse fuentes confiables para las conclusiones avanzadas por Espoo . - Dgtsyb ( charla ) 00:01, 2 de enero de 2010 (UTC)
- Específicamente no descarté la única fuente confiable proporcionada en mayúsculas de soporte. Simplemente señalé que las obras de referencia como Britannica basan sus elecciones en una visión integral del uso, mientras que el editor del libro de McGraw Hill es solo la preferencia personal de una persona o un grupo pequeño. Y MOS dice claramente que hay que evitar mayúsculas innecesarias, que es claramente el caso cuando ambos son utilizados por fuentes confiables. Dado que su punto de vista está luchando contra los molinos de viento combinados de Britannica, ITU e IEC, el caso es especialmente claro. - Espoo ( charla ) 16:50, 1 de enero de 2010 (UTC)
- ¿Dónde está documentada la extensa investigación de Britannica sobre el uso? Esto me suena más a una investigación personal. La UIT, excepto en títulos que son un asunto diferente (estilo de la casa), hace lo que hacen otras fuentes sobre el tema: es decir, expandirlo una vez, escribirlo con mayúscula en la introducción y luego simplemente usar el acrónimo en el resto del documento. De esa manera, ahorra papel y tinta. Esto es lo que hace la Recomendación UIT-T I.150 , al igual que la Teoría y aplicaciones ATM , McGraw Hill, ATM Volumen III, Internetworking con ATM , Prentice Hall. ISO / IEC hace lo mismo en, por ejemplo, ISO / IEC 13246: 1997 (E) e ISO / IEC 13247: 1997 (E). Por tanto, no creo que los documentos de la UIT e ISO / IEC apoyen su conclusión.
- Recuerdo de documentos de trabajo anteriores tanto en ISDN como en ATM que, antes de que se estandarizaran, solíamos referirnos a ellos en minúsculas y después de la estandarización en mayúsculas. Quizás Britannica esté siguiendo este uso arcano.
- La base de datos RFC es una buena forma de descubrir el uso común. En las siguientes RFC siempre se escribe con mayúscula como Modo de transferencia asíncrona : RFC 1167, RFC 1340, RFC 1391, RFC 1392, RFC 1483, RFC 1539, RFC 1573, RFC 1577, RFC 1599, RFC 1607, RFC 1679, RFC 1680, RFC 1700, RFC 1705, RFC 1709, RFC 1718, RFC 1754, RFC 1821, RFC 1983, RFC 2071, RFC 2225, RFC 2226, RFC 2233, RFC 2299, RFC 2381, RFC 2400, RFC 2502, RFC 2600, RFC 2626, RFC 2684, RFC 2761, RFC 2799, RFC 2863, RFC 2885, RFC 2955, RFC 2999, RFC 3015, RFC 3031, RFC 3035, RFC 3038, RFC 3094, RFC 3116, RFC 3133, RFC 3134, RFC 3175, RFC 3199 , RFC 3215, RFC 3292, RFC 3293, RFC 3294, RFC 3295, RFC 3299, RFC 3300, RFC 3336, RFC 3337, RFC 3353, RFC 3355, RFC 3386, RFC 3441, RFC 3471, RFC 3496, RFC 3499, RFC 3525, RFC 3600, RFC 3700, RFC 3809, RFC 3815, RFC 3819, RFC 4048, RFC 4110, RFC 4221, RFC 457, RFC 4294, RFC 4297, RFC 4364, RFC 4365, RFC 4368, RFC 4381, RFC 4447, RFC 4454, RFC 4542, RFC 4553, RFC 4603, RFC 4638, RFC 4679, RFC 4710, RFC 4717, RFC 4766, RFC 4779, RFC 4782, RFC 4803, RFC 4816, RF C 4821, RFC 4840, RFC 4842, RFC 4905, RFC 4906, RFC 4949, RFC 5000, RFC 5070, RFC 5085, RFC 5254, RFC 5287, RFC 5494, y la lista continúa ... Solo una vez en una RFC que Puedo encontrar que se conoce como modo de transferencia asincrónica : RFC 3819, y en ese RFC también aparece una vez como modo de transferencia asincrónica . Esta lista abarca 20 años de uso común. 156 ocurrencias del modo de transferencia asincrónica y 1 ocurrencia del modo de transferencia asincrónica .
- La serie Q de la UIT se desglosa de esta manera: modo de transferencia asincrónica , Q.1201, Q.2010, Q.2100, Q.2110, Q.2120, Q.2130, Q.2140, Q.2144, Q.2761, Q.2762, Q.2763, Q.2764, Q.2971; modo de transferencia asincrónica , ninguno. Serie I: modo de transferencia asíncrona , I.150, I.312, I.326, I.361, I.364, I.365-1, I.365-2, I.365-3, I.374, I.555, I.731, I.751; modo de transferencia asíncrona , I.321, I.327. Quizás una confusión para algunos es que algunos documentos hablan de los aspectos generales de un modo de transferencia asincrónica . Esto se debe a que este uso es un sustantivo común. En ese momento, sabíamos que un modo de transferencia asincrónica eventualmente se estandarizaría, pero no estaba seguro de qué propuestas específicas se adoptarían. (Ni siquiera sabíamos el tamaño de la celda, por ejemplo). Pero una vez que se decidieron los aspectos generales y se estandarizaron todos los detalles, se lo denominó comúnmente Modo de transferencia asincrónica , ya que en el concepto estandarizado no se han determinado solo los aspectos generales .
- No creo que le dé mucho más esfuerzo. Lo siento, pero no puedo suscribirme a su teoría de Britannica investigando a fondo el uso común en este caso, o en el de ISDN o B-ISDN para el caso. - Dgtsyb ( conversación ) 21:30, 1 de enero de 2010 (UTC)
- Algunas adiciones más. Documentos del Foro ATM: CS 107, CS 115, CS 125, CS 126, CS 127, CS 135, CS 140, CS 141, FBATM 139, LANE 38, LANE 112, MPOA 114, MPOA 129, NM 19, NM 27, NM 58, NM 73, NM 95, NM 103, NM 122, NM 184, PHY 43, PHY 79, PHY 86, PHY 110, PHY 128, PHY 130, PHY 133, PHY 134, PHY 138, PHY 142, PHY 143, PHY 144, PHY 162, PNNI 66, PNNI 81, RA 104, RA 105, RA 106, RA 123, RBB 99, RBB PY 101, SAA 108, SAA 109, SAA 124, SEC 100, PRUEBA 30, PRUEBA 42, PRUEBA 44, PRUEBA 51, PRUEBA 52, PRUEBA 67, PRUEBA 70, PRUEBA 90, PRUEBA 137, PRUEBA CSRA 111, PRUEBA CSRA 118, PRUEBA TM 131, TM 121, VTOA 83, VTOA 89, VTOA 113, VTOA 119, VTOA 120, VTOA 132: ortografía del modo de transferencia asincrónica , todos; modo de transferencia asincrónica , ninguno. Una década de uso ... - Dgtsyb ( charla ) 22:20, 1 de enero de 2010 (UTC)
- Una nota más: no parece querer considerar cómo los ingenieros usan el término y, sin embargo, el término no se usa comúnmente fuera del campo de la ingeniería. Fuera del campo de la Ingeniería, un cajero automático es una máquina de la que sacas todo tu dinero; Dentro del campo de la Ingeniería, ATM es una máquina que se lleva todo su dinero. ;) - Dgtsyb ( conversación ) 22:01, 1 de enero de 2010 (UTC)
Tarde para la fiesta, no me voy a molestar en responder a todos los puntos anteriores. Basta con decir que, en mi experiencia el uso común de transferencia asíncrona Modo está siempre en mayúsculas; No veo ninguna razón por la que Wikipedia debería ser la excepción. // Blaxthos ( t / c ) 22:08, 1 de enero de 2010 (UTC)
Eche un vistazo al nombre propio . El modo de transferencia asincrónica es un estándar específico y solo se puede considerar como un nombre propio y, por lo tanto, debe escribirse con mayúscula. Como no se puede garantizar que otros autores hayan seguido correctamente los requisitos sintácticos, no se debe basar su argumento en el uso común. En cambio, uno debería basar su argumento en principios sintácticos. Desde esta perspectiva, solo se permiten los cajeros automáticos en mayúscula. Este enfoque puede parecer contrario a la filosofía de WP, sin embargo, es la única forma de resolver conflictos como este donde el uso común es a menudo gramaticalmente incorrecto. Internet / Internet, como se mencionó anteriormente, es otro ejemplo. - Spuzzdawg ( charla ) 22:42, 18 de diciembre de 2010 (UTC)
En la actualidad, el título está en minúsculas y el encabezado está en Title Case. Creo que ATM es un nombre propio como Red digital de servicios integrados , Frame Relay , Conmutación de etiquetas multiprotocolo y Ethernet, por lo que prefiero el caso del título. Como mínimo, debemos ser coherentes con nosotros mismos. Si no hay más discusión, solicitaré un movimiento para cambiar el título para que coincida con el líder. ~ Kvng ( charla ) 14:35, 5 de noviembre de 2019 (UTC)
- En general, estoy de acuerdo con el análisis de Dgtsyb. Y esto (creo que por Kbrose) es falaz: 'I.150 no pondría en minúscula "modo de transferencia asincrónica" en ningún lugar si fuera un nombre propio.' Presume que el (los) autor (es) de I.150 fueron escritores infalibles. La preponderancia de la evidencia está fuertemente a favor de que este sea un nombre propio (frase de nombre propio), no una frase de nombre común. - SMcCandlish ☏ ¢ 😼 15:41, 26 de octubre de 2020 (UTC)
Un terrible error
Algunos llaman a este protocolo "un terrible error". Ver http://www.clock.org/~fair/opinion/atm-is-bad.html Emersion ( charla ) 11:17, 15 de diciembre de 2017 (UTC)
- Bueno, tiene 20 años (tenga en cuenta el comentario sobre el próximo gigabit ethernet). Pero por lo demás, ATM fue diseñado para compañías telefónicas, no para uso de LAN o WAN. Sin embargo, VoIP aún no está cerrando las compañías telefónicas. Pero sí, LANe no es una buena forma de ejecutar una LAN. Deje el cajero automático a las compañías telefónicas. Gah4 ( charla ) 14:31, 15 de diciembre de 2017 (UTC)
- Eso parece un WP: SPS . Consulte la discusión sobre #ATM (Otro error técnico) más arriba. ~ Kvng ( charla ) 14:29, 22 de mayo de 2020 (UTC)
Movimiento solicitado 16 de septiembre de 2020
- La siguiente es una discusión cerrada de una mudanza solicitada . Por favor no lo modifique. Los comentarios posteriores deben hacerse en una nueva sección de la página de discusión. Los editores que deseen impugnar la decisión final deben considerar una revisión de movimiento después de discutirlo en la página de discusión del cerrador. No se deben realizar más ediciones en esta discusión.
El resultado de la solicitud de movimiento fue: No movido : un consenso aproximado de no mover el artículo ( cierre de no administrador ) Megan☺️ Habla con el monstruo 18:16, 23 de septiembre de 2020 (UTC)
Modo de transferencia asincrónica → Modo de transferencia asincrónica : consulte la discusión de hace 10 años, en Talk: Asynchronous Transfer Mode # minúsculas correctas sobre si el título tiene o no letras mayúsculas. Anthony Appleyard ( charla ) 09:24, 16 de septiembre de 2020 (UTC)
- Por favor, no empieces de nuevo con esta extraña charla. Fue el consenso de los editores con conocimientos técnicos que este es un nombre propio, respaldado por la gran mayoría de la literatura temática, incluidas docenas de RFC del IETF. Además, WP pone en mayúsculas todos los nombres de protocolos específicos. kbrose ( charla ) 12:36, 16 de septiembre de 2020 (UTC)
- Oponerse - nombre propio, recién corregido - Zac67 ( hablar ) 16:57, 16 de septiembre de 2020 (UTC)
- Oponerse . Este es un nombre propio y, por lo tanto, debe escribirse con mayúscula. J I P | Charla 17:47, 16 de septiembre de 2020 (UTC)
- Neutral : en la última discusión de RM en Talk: Asynchronous_Transfer_Mode / Archive_2 # Requested_move_4_June_2018 no hubo mucha entrada, pero se dejó en minúsculas donde Tony1 lo había puesto antes. Apoyé la eliminación del paréntesis y no investigué mucho el caso. Estoy de acuerdo en que es un protocolo con nombre, por lo que probablemente las mayúsculas estén bien. Dicklyon ( charla ) 23:02, 17 de septiembre de 2020 (UTC)
- Y vea la discusión anterior sobre esto, si esto vuelve a surgir. Se ha presentado una gran cantidad de evidencia de que este es un nombre propio, y básicamente nada para lo contrario, aparte de que estaba mal escrito en un puñado de viejos RfC. - SMcCandlish ☏ ¢ 😼 15:45, 26 de octubre de 2020 (UTC)