|
aha -
well, that is an excellent question.
i
think the implementors have converged on the value 1, presumably by
telepathy...
i will
add a note to the tracker on this.
thanks,
r.
Hi
Robert,
your reasoning sounds
OK to me. Just one additional question:
Is the current GIST
spec Version 0 or 1? I did not find any value
in the
draft.
Christian
Dickmann
From: Hancock, Robert
[mailto:robert.hancock at roke.co.uk]
Sent: Saturday, March 25, 2006
1:25 PM
To: Christian Dickmann; nsis-imp at lists.ietf.org
Subject: RE: [Nsis-imp] Unknown GIST
version number
Hi Christian,
It's a good question, and
deserves some discussion. The rationale
is in fact based on a consideration
of what we should define now
to ease deployment in the future:
*) at
the moment there is only one version, so the condition is not
exercised
(except by erroneous implementations)
*) if a new version is created
(which I doubt in the near future),
then the specification will have to
define how to handle backwards
compatibility. if the new version includes
the old as a subset, then
the question will be whether to try the newest
version by default or
not when initiating signalling. for the long term
efficiency, it's
nicer to be optimistic and leave open the option to
negotiate down.
In this case, if the rule was 'forward transparently'
then the first
node to deploy the new version would never find any peers,
even though
it could interact quite happily with nodes supporting earlier
versions.
The 'reject with error' rule allows the node to detect the
condition
and retry with a lower version number (in fact, it should be able
to
choose immediately the right version based on what is reported in
the
error).
Hope this seems
reasonable,
r.
-----Original Message-----
From: Christian
Dickmann [mailto:mail at christian-dickmann.de]
Sent:
Fri 24/03/2006 18:03
To: nsis-imp at lists.ietf.org
Subject: [Nsis-imp]
Unknown GIST version number
Hi Robert,
I got a question about an
error condition:
In GIST-09 A.1. the draft says:
"Parsing failures may
be caused by unknown Version or Type values,
inconsistent R
flag setting, or a Message Length inconsistent with
the set of
objects carried. In all cases the receiver MUST if
possible return a "Common Header Parse Error" message
(Appendix A.4.4.1) with the appropriate subcode, and not process
the
message further."
I wonder if an unknown version
should really result in an error.
If the node is just an intermediate node,
why shouldn't it just forward
the message? Otherwise new GIST versions
could be a deployment problem.
Did I miss some note in the draft about this
topic, or is there any
other reasoning?
Thanks,
Christian
Dickmann
_______________________________________________
NSIS-imp
mailing list
NSIS-imp at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/nsis-imp
--
Visit our website at www.roke.co.uk
Roke Manor Research
Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
The information
contained in this e-mail and any attachments is proprietary to
Roke Manor
Research Ltd and must not be passed to any third party without
permission.
This communication is for information only and shall not create or
change
any contractual relationship.
--
Visit our website at www.roke.co.uk
Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
The information contained in this e-mail and any attachments is proprietary to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.
|
