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 ;)
--
Iñaki Baz Castillo