Re: [hybi] RFC 6455 - conflicting statements

[Alexey Melnikov <[e-mail]>]

Hi,

On 29/04/2012 18:02, Nataraju A.B wrote:
> Alex,
>
> Sorry for confusion. The comment should have been other way round. I 
> mean sections 1.1-1.9 shall be normative like other sections.
Ok, this makes more sense.
>
> For example, Opening Handshake, Closing Handshake, Establishing a 
> Connection are mandatory to implement. Hence these sections must be 
> mentioned as normative text. therefore the text "_This section is 
> non-normative._" shall be removed in these sections.
It is possible that some of these are indeed normative. Happy to review 
that once the document is reopened for update. But note that some of 
these sections introduce concepts informative, which are then defined 
normatively in later sections. No real conflict here.
>
> Thanks,
> Nataraju A B
>
> On Sun, Apr 29, 2012 at 9:55 PM, Alexey Melnikov 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Hi,
>
>
>     On 27 Apr 2012, at 11:21, "Nataraju A.B" <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>>
>>
>>     On Fri, Apr 27, 2012 at 3:11 PM, Alexey Melnikov
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>         On 27 Apr 2012, at 10:05, "Nataraju A.B"
>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>>         Hi All,
>>
>>         Hi,
>>
>>>
>>>         Following is the snippet from the RFC6455.
>>>
>>>         <RFC6455>
>>>         2.  Conformance Requirements
>>>
>>>             All diagrams, examples, and notes in this specification are non-
>>>             normative, as are all sections explicitly marked non-normative.
>>>             *_Everything_*else in this specification is normative.
>>>
>>>         1.9.  Subprotocols Using the WebSocket Protocol
>>>
>>>             _This section is non-normative._
>>>
>>>             The client can request that the server use a specific subprotocol by
>>>             including the |Sec-WebSocket-Protocol| field in its handshake.  If it
>>>             is specified, the server needs to include the same field and one of
>>>             the selected subprotocol values in its response for the connection to
>>>             be established.
>>>
>>>         3.  WebSocket URIs
>>>
>>>             This specification defines two URI schemes, using the ABNF syntax
>>>             defined in RFC 5234 [RFC5234], and terminology and ABNF productions
>>>             defined by the URI specification RFC 3986 [RFC3986].
>>>
>>>                    ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
>>>                    wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]
>>>
>>>                    host =<host, defined in [RFC3986], Section 3.2.2>
>>>                    port =<port, defined in [RFC3986], Section 3.2.3>
>>>                    path =<path-abempty, defined in [RFC3986], Section 3.3>
>>>                    query =<query, defined in [RFC3986], Section 3.4>
>>>         </RFC6455>
>>>
>>>         *Comment*: According to statement in sec 2, section 3 -
>>>         WebSocket URIs (for example) is normative. But I don't think
>>>         that it correct. Section 3, 4, 5, 6, 7, 8 must also be
>>>         changed as non-normative text by inserting the text "_This
>>>         section is non-normative._".
>>>
>>
>>         Can you elaborate why you think that these sections are
>>         non-normative?
>>
>>     [ABN] In this context, We understand normative means informative
>>     text. It is not mandatory to implement or refer normative text.
>>     But it is mandatory to follow syntax and semantics of
>>     non-normative text / information. AFAIU sections 3-8 of rfc6455
>>     are mandatory to implement. Hence it must be mentioned as
>>     non-normative text "_This section is non-normative._", like
>>     mentioned for sections 1.1-1.9
>
>     Sorry, I am very confused. Non-normative and Informative have the
>     say meaning. They definitely don't equate to "normative". Specific
>     syntax, like ws: URI in Section 3 is normative, as it defines
>     specific rules that are necessary to follow to implement ws: URI
>     parsing, generation or processing.
>
>>
>>>         Otherwise, Am I missing something here ???
>>>
>>>         Thanks,
>>>         Nataraju A.B.
>>
>>
>
>
>
> -- 
> Thanks,
> Nataraju A.B.
>