Hello Gonzales,

In message <[EMAIL PROTECTED]> Gonzalo Camarillo 
<[EMAIL PROTECTED]> writes:
>Therefore, comments about the actual format are very welcome. Other
>comments are interesting for other documents, but I do not think the
>IESG has to be involved in such a discussion until those documents are
>done. 

        Would it be impossible (or too late) to align your spec with the
        updated format in sdp-new-04? It fixes the errors in your ABNF
        and it is mostly consistent with the syntax in RFC 2327.

        I have cut and pasted relevant ABNF from sdp-new-04 and RFC 2327
        (FQDN and TTL are from old SDP) below. It is not strictly
        compatible with RFC 2327 as it fixes a bug with
        multicast-address rule (which could have more than 4 octets in
        RFC 2327):

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
3. Syntax

   RFC2373 [1] gives an ABNF for the text representation of IPv6 addresses in 
   Appendix B. RFC2732 [3] covers the text representation of IPv6 addresses 
   when used within a URL. Using the ABNF described in these documents, the 
   following updated ABNF for SDP is proposed.

   connection-address =  multicast-address
                         | addr

   multicast-address =   addr "/" ttl [ "/" integer ]
        ;IPv4 multicast addresses must be in the range
        ;224.0.0.0 to 239.255.255.255
        ;IPv6 multicast addresses must begin with the byte FF
        ;or include an IPv4 multicast address

   ttl =                 decimal-uchar

   addr =                FQDN | unicast-address

   unicast-address =     IP4-address | IP6-address

   FQDN =                4*(alpha-numeric|"-"|".")
                         ;fully qualified domain name as specified in RFC1035

   ; IP4-address, IP6-address: From RFC 2373
   IP6-address =         hexpart [ ":" IP4-address ]
   IP4-address =         1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT

   hexpart =             hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
   hexseq =              hex4 *( ":" hex4)
   hex4 =                1*4HEXDIG

   uri =                 URI-reference ; defined in RFC2396/2732

   ; decimal-uchar, integer, and alpha-numeric are defined in RFC2327

-->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8--

        You could also discuss how TTL should be used with IPv6
        addresses. While TTL is nice thing and makes it easy to
        recognize multicast addresses, it is not compatible with RFC2327
        syntax. So, I propose something like following:

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
4.2 IPv6 and Multicast Addresses

    The IPv6 multicast addresses have the following format:

   |   8    |  4 |  4 |                  112 bits                   |
   +------ -+----+----+---------------------------------------------+
   |11111111|flgs|scop|                  group ID                   |
   +--------+----+----+---------------------------------------------+

    A 8-bit prefix of all ones at the start of the address identitifies
    a multicast address. The text representation of the IPv6 multicast
    addresses begins always with a four-digit hex segment starting with
    "FF".

    Following the prefix are three reserved bits, initialized to zero,
    and a flag indicating how the address has been assigned. In text
    representation, the third hex-digit indicates if the multicast
    address is well-known (even digit) or transient (odd digit).

    The following four bits, scop, indicates the scope of the multicast
    address. The scop is the fourth hex-digit in the text
    representation. There is no TTL in IPv6, but the scope and group ID
    together identifies the multicast group.

    For multicast addresses mapped uniquely to IEEE 802 MAC addresses,
    the next 80 bits or 20 hex digits are reserved and must be zero. The
    last 32 bits identitifies the group within given scope.

   |   8    |  4 |  4 |          80 bits          |     32 bits     |
   +------ -+----+----+---------------------------+-----------------+
   |11111111|flgs|scop|   reserved must be zero   |    group ID     |
   +--------+----+----+---------------------------+-----------------+

4.2.1 Using TTL with IPv6 Multicast Address

    Conferences using an IPv6 multicast connection address SHOULD also
    have a time to live (TTL) value present in addition to the multicast
    address. The TTL and the IPv4 address together define the scope with
    which multicast packets sent in this conference will be sent. When
    an IPv4-compatible-IPv6 or IPv4-mapped-IPv6 address is used, TTL
    value MUST be in the range 0-255.

    When an IPv6 multicast connection address is used, a TTL value of 0
    SHOULD is included.

    The TTL for the session is appended to the address using a slash as
    a separator.  Examples are:

         c=IN IP6 FF1E::172A:1E24/0

         c=IN IP6 ::233.42.30.36/16
-->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8--


                                                Pekka



--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to