El Viernes, 4 de Abril de 2008, samuel escribió:
¡Cómo no! ¡¡¡cómo va el IETF a restringir/especificar algo en concreto!!! ¡para qué decir las cosas claramente pudiendo hablar en abstracto y que cada implementador interprete lo que le salga de los catapli***!
es parte de los problemas de hacer cosas que funcionen "en general" sin casos particulares.
Seguro que sí, pero a estas alturas yo todavía no conozco, por ejemplo, dos implementaciones SIP que interoperen correctamente en presencia SIMPLE con más de los estados básicos "online/offline". Todos los estados "secundarios" (busy, away...) sólo funcionan con clientes iguales.
Es curioso, los RFC están ahí, por ejemplo el RFC4480 (RPID: Rich Presence Extensions to the Presence Information Data Format), pero claro, ¿quién demonios se va a molestar en implementar estados tan absurdos como?:
------------------------------------------------------- 3.2. Activities Element
breakfast: The person is eating the first meal of the day, usually eaten in the morning.
dinner: The person is having his or her main meal of the day, eaten in the evening or at midday.
holiday: This is a scheduled national or local holiday.
in-transit: The person is riding in a vehicle, such as a car, but not steering. The <place-type> element provides more specific information about the type of conveyance the person is using.
looking-for-work: The presentity is looking for (paid) work.
lunch... meal...
playing: The person is occupying himself or herself in amusement, sport, or other recreation.
presentation: The person is giving a presentation, lecture, or participating in a formal round-table discussion.
shopping: The person is visiting stores in search of goods or services.
sleeping: This activity category can often be generated automatically from a calendar, local time information, or biometric data.
spectator: The person is observing an event, such as a sports event.
tv: The person is watching television.
worship: The presentity is participating in religious rites.
etc etc... -------------------------------------------------------
Personalmente flipo con los estados "rezando, jugando, viendo la TV, buscando trabajo...", ¡¡¡flipo mucho!!!
Y esto por no hablar de los "moods" (estado de ánimo):
o afraid o amazed o angry o annoyed o anxious o ashamed o bored o brave ... ... o nervous o neutral o offended o other o playful o proud o relieved o remorseful
Es alucinante, ¿quién ha aprobado este enjendro?
Ah claro claro, entiendo... no se mojan en decir "debe ser TLS o IPSEC" no sea que se dejen en el tintero algún protocolo capa 3 completamente deprecated tipo IPX. Dios mío ¡¡¡compatibilidad hacia atrás!!!
o hacía delante.....que es uno de los puntos fuertes de SIP, la extensibilidad cara al futuro. Pasa lo mismo con la especificación del transporte utilizado.
Estoy de acuerdo, pero no creo que esté de más mojarse un poco y al menos mencionar los casos que YA existen. O sea, si dices que "tal sólo es una red segura" al menos dígnate a decir:
"Una red segura puede ser una VPN privada, una conexión con IPSEC, uso de SIP TLS... y además se contemplan nuevas tecnologías de red futuras que se denominen seguras".
Al menos la gente que vive **ahora** sabría cuándo una red es segura o no en el escenario actual.
¿Para qué hacer la gramática ABNF de SIP sencilla y fácil de parsear si podemos basarla en gramáticas de hace 20 años como el HTTP y SMTP con todos sus fallos de diseño y eficiencia por ser megapermisivos sin corregir NI UNO SOLO!!
PD: ¿A que se nota que estoy haciendo un parser SIP y estoy to' quemao? XDDD
ánimus que así se aprende ;)
Eso sí, se aprende a todo: - A programar. - A parsear. - A leer. - A despotricar XDDD
PPD: Gramática RFC3261 de la cabecera "Via" [1] convertida a RegExp: [1] http://www.tech-invite.com/Ti-sip-abnf-hf.html#Via
Ala, sencillita, eficiente y ligera. XDDD
la quito de la respuesta no sea que me bloquee el gestor de la lista el correo por demasiado grande ;)
Pues no te pongo entonces el RequestURI XDDDD
Saludos ;)