https://foro.gambas-es.org/viewtopic.php?f=1&t=365&p=2057#p2057
-----------------------------------
soplo
Jueves, 21 Enero 2010, 00:17

Re: Implementar Servicio SMS De Lleida.net En Un Programa?
-----------------------------------
Aquí está un extracto de la RFC 5724

Definición de campos
[quote]2.2.  Formal Definition

   The URI scheme's keywords specified in the following syntax
   description are case-insensitive.  The syntax of an "sms" URI is
   formally described as follows, where the URI base syntax is taken
   from [RFC3986]:

  sms-uri        = scheme ":" sms-hier-part [ "?" sms-fields ]
  scheme         = "sms"
  sms-hier-part  = sms-recipient *( "," sms-recipient )
  sms-recipient  = telephone-subscriber ; defined in RFC 3966
  sms-fields     = sms-field *( "&" sms-field )
  sms-field      = sms-field-name "=" escaped-value
  sms-field-name = "body" / sms-field-ext ; "body" MUST only appear once
  sms-field-ext  = 1*( unreserved )
  escaped-value  = *( unreserved / pct-encoded ) ; defined in RFC 3986

Wilde & Vaha-Sipila         Standards Track                     [Page 7]

RFC 5724                    sms" URI Scheme                 January 2010


   Some illustrative examples using this syntax are given in
   Section 2.5.

   The syntax definition for <telephone-subscriber> is taken from
   Section 5.1 of [RFC3966].  Please consider Erratum 203 [Err203] in
   that specification.  For the reader's convenience, Appendix A
   contains a fixed syntax of the telephone number URI scheme, including
   Erratum 203, but RFC 3966 (plus all applicable errata) is the
   normative reference.  The description of phone numbers in RFC 3966
   (Section 5.1) states: "The 'telephone-subscriber' part of the URI
   indicates the number.  The phone number can be represented in either
   global (E.164) or local notation.  All phone numbers MUST use the
   global form unless they cannot be represented as such.  Numbers from
   private numbering plans, emergency ("911", "112"), and some
   directory-assistance numbers (e.g., "411") and other "service codes"
   (numbers of the form N11 in the United States) cannot be represented
   in global (E.164) form and need to be represented as a local number
   with a context.  Local numbers MUST be tagged with a 'phone-
   context'."

   This specification defines a single <sms-field>: "body".  Extensions
   to this specification MAY define additional fields.  Extensions MUST
   NOT change the semantics of the specifications they are extending.
   Unknown fields encountered in "sms" URIs MUST be ignored by
   implementations.

   The "body" <sms-field> is used to define the body of the SMS message
   to be composed.  It MUST not appear more than once in an "sms" URI.
   It consists of percent-encoded UTF-8 characters.  Implementations
   MUST make sure that the "body" <sms-field> characters are converted
   to a suitable character encoding before sending, the most popular
   being the 7-bit SMS character encoding, another variant (though not
   as universally supported as 7-bit SMS) is the UCS-2 character
   encoding (both specified in [SMS-CHAR]).  Implementations MAY choose
   to discard (or convert) characters in the <sms-body> that are not
   supported by the SMS character set they are using to send the SMS
   message.  If they do discard or convert characters, they MUST notify
   the user.

   The syntax definition for <escaped-value> refers to the text of an
   SMS where all <reserved> (as per [RFC3986]) characters in the SMS
   text are percent-encoded, please refer to [RFC3986] for the
   definitions of <unreserved> and <pct-encoded> and for details about
   percent-encoding.

   User agents SHOULD support multiple recipients and SHOULD make it
   clear to users what the entire list of recipients is before
   committing the user to sending all the messages.
[/quote]

Procesar el sms
[quote]  Processing an "sms" URI

   The following list describes the steps for processing an "sms" URI:

   1.  The phone number of the first <sms-recipient> is extracted.  It
       is the phone number of the final recipient and it MUST be written
       in international form with country code, unless the number only
       works from inside a certain geographical area or a network.  Note
       that some numbers may work from several networks but not from the
       whole world -- these SHOULD be written in international form.
       According to [RFC3966], all international numbers MUST begin with
       a "+" character.  Hyphens, dots, and parentheses (referred to as
       "visual separators" in RFC 3966) are used only to improve
       readability and MUST NOT convey any other meaning.

   2.  The "body" <sms-field> is extracted, if present.

   3.  The user agent SHOULD provide some means for message composition,
       either by implementing this itself or by accessing a service that
       provides it.  Message composition SHOULD start with the body
       extracted from the "body" <sms-field>, if present.

   4.  After message composition, a user agent SHOULD try to send the
       message first using the default delivery method employed by that
       user agent.  If that fails, the user agent MAY try another
       delivery method.

   5.  If the URI contains a comma-separated list of recipients (i.e.,
       it contains multiple <sms-recipient> parts), all of them are
       processed in this manner.  Exactly the same message SHOULD be
       sent to all of the listed recipients, which means that the
       message resulting from the message composition step for the first
       recipient is used unaltered for all other recipients as well.

[/quote]

Comparación de SMS
[quote]   Two "sms" URIs are equivalent according to the following rules.
   Since the definition of the <telephone-subscriber> is taken from
   [RFC3966], equivalence of individual values of <telephone-subscriber>
   is based on the rules defined in Section 4 of [RFC3966], repeated
   here for convenience:

   o  Both must be either a <local-number> or a <global-number<, i.e.,
      start with a "+".

   o  The <global-number-digits> and the <local-number-digits> must be
      equal, after removing all visual separators.

Wilde & Vaha-Sipila         Standards Track                     [Page 9]

RFC 5724                    sms" URI Scheme                 January 2010

   o  For mandatory additional parameters and the <phone-context> and
      <extension> parameters defined in [RFC3966], the <phone-context>
      parameter value is compared either as a host name if it is a
      <domainname> or digit-by-digit if it is <global-number-digits>.
      The latter is compared after removing all <visual-separator>
      characters.

   o  Parameters are compared according to <pname>, regardless of the
      order they appeared in the URI.  If one URI has a parameter name
      not found in the other, the two URIs are not equal.

   o  URI comparisons are case-insensitive.

   Since "sms" URIs can contain multiple <telephone-subscriber>s as well
   as <sms-fields>, in addition to adopting the rules defined for
   comparing <telephone-subscriber>s as defined by [RFC3966], two "sms"
   URIs are only equivalent if their <sms-fields> are identical, and if
   all <telephone-subscriber>s, compared pairwise as a set (i.e.,
   without taking sequence into consideration), are equivalent.
[/quote]

Como verás si lees la rfc encontrarás que a menudo se refiere a otra RFC. Por ejemplo hay una RFC para definir como es un número de teléfono y por tanto para describir el número de teléfono de un sms se remite a un número válido según esa RFC. Por eso son estándares.

Ahí tienes toda la información de campos, protocolos, condiciones de validación, etc para que debe cumplir tu software. Como tu solo quieres enviar un sms de vez en cuando no te compete toda la RFC. Busca las condiciones válidas para un envío de SMS, haz un form con esos datos, y el botón de enviar que compruebe lo que la RFC define como condiciones de sms válido. Con eso cuando envies el paquete la compañía telefónica no te lo devolverá por inválido y ya es problema suyo que llegue a quien tenga que llegar.


