In 1) you define both a sending requirement and a receiving requirement for the existing codepoint. In 2 you define only a receiving requirement, and do not allow new implementations to send it (i.e. it is there only for dealing with legacy implementations that send it).
regards
Keith
> -----Original Message-----
> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
> Sent: Monday, June 22, 2009 1:00 AM
> To: DRAGE, Keith (Keith); James M. Polk; Bernard Aboba;
> rbarnes@bbn.com; mlinsner@cisco.com
> Cc: geopriv@ietf.org
> Subject: RE: [Geopriv] Datum field changes in RFC 3825bis
> (affecting Sections 2, 2.1 and 6.2)
>
> Hi Keith,
>
> I don't see any practical difference between the outcome of 1
> and 2. It's an exercise in labelling that materially changes
> nothing. We waste too much time on labelling.
>
> --Martin
>
> > -----Original Message-----
> > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> > Sent: Saturday, 20 June 2009 2:14 AM
> > To: James M. Polk; Bernard Aboba; Thomson, Martin; rbarnes@bbn.com;
> > mlinsner@cisco.com
> > Cc: geopriv@ietf.org
> > Subject: RE: [Geopriv] Datum field changes in RFC 3825bis
> (affecting
> > Sections 2, 2.1 and 6.2)
> >
> > I dont agree with the specifics of:
> >
> > > Given that this bis doc is going to obsolete 3825, then
> this bis doc
> > > is defining both version 0 and 1 - because someone can
> still choose
> > > (and I'm not sure why they would, but they
> > > could) to implement only what works in version 0 of this spec.
> > >
> > > That this doc specifies both v0 and v1 needs to be said
> if anything
> > > is said., and I think something needs to be said - given we're
> > > obsoleting 3825 "for cause".
> > >
> >
> > The fact that the bis exists does not remove RFC 3825 from
> existence,
> > it merely labels it obsolete. Moreover implementations to RFC 3825
> > continue to exist. There is no automatic requirement that an
> > implementation conformant to RFC 3825 is also conformant to the bis.
> > What we need is compatibility. So in effect two options
> exist for each
> > change (between which the group has to decide) while maintaining
> > compatibility:
> >
> > 1) The existing behaviour is decided by the group to be useful for
> > new implementations, in addition to the proposed new behaviour. In
> > which case, the bis document defines both (for both sender and
> > receiver).
> >
> > 2) The existing behaviour is decided by the group to be not
> > preferred. In that case the new behaviour is specified. For
> > compatibility with existing implementations, new
> implementations have
> > to be required to receive what old implementations send.
> >
> > There is a third option that the existing behaviour is so
> broken that
> > existing implementations do not work with each other, in which case
> > any compatibility requirements are moot. This however does
> not apply
> > in this case.
> >
> > regards
> >
> > Keith
> >
> > > -----Original Message-----
> > > From: geopriv-bounces@ietf.org
> > > [mailto:geopriv-bounces@ietf.org] On Behalf Of James M. Polk
> > > Sent: Thursday, June 11, 2009 10:42 PM
> > > To: Bernard Aboba; martin.thomson@andrew.com; rbarnes@bbn.com;
> > > mlinsner@cisco.com
> > > Cc: geopriv@ietf.org
> > > Subject: Re: [Geopriv] Datum field changes in RFC 3825bis
> (affecting
> > > Sections 2, 2.1 and 6.2)
> > >
> > > Given that this bis doc is going to obsolete 3825, then
> this bis doc
> > > is defining both version 0 and 1 - because someone can
> still choose
> > > (and I'm not sure why they would, but they
> > > could) to implement only what works in version 0 of this spec.
> > >
> > > That this doc specifies both v0 and v1 needs to be said
> if anything
> > > is said., and I think something needs to be said - given we're
> > > obsoleting 3825 "for cause".
> > >
> > > At 11:47 PM 6/10/2009, Bernard Aboba wrote:
> > > >Thanks for pointing out the error.
> > > >
> > > >I guess we're pointing out that implementers should check the
> > > >length field, then look at the 2 most significant bits
> of the last
> > > >octet to determine the version, rather than just
> assuming that the
> > > length = 16.
> > > >
> > > >Should we point out that RFC 3825 was version 0, and that this
> > > >specification defines version 1?
> > > >Some text probably belongs in the IANA considerations section
> > > >describing how version numbers are allocated (presumably by
> > > Standards
> > > >Action, no?)
> > > >
> > > >
> > > >----------
> > > >Subject: RE: Datum field changes in RFC 3825bis (affecting
> > > Sections 2,
> > > >2.1 and 6.2)
> > > >Date: Wed, 10 Jun 2009 23:29:28 -0500
> > > >From: Martin.Thomson@andrew.com
> > > >To: bernard_aboba@hotmail.com; jmpolk@cisco.com;
> rbarnes@bbn.com;
> > > >mlinsner@cisco.com
> > > >CC: geopriv@ietf.org
> > > >
> > > >Hi Bernard,
> > > >
> > > >
> > > >
> > > >I think that you have these back to front. The version tags
> > > need to go
> > > >in the MSB, so that old versions using the LSBs aren't
> > > affected. Other
> > > >than that, I think that it's OK.
> > > >
> > > >
> > > >
> > > >Is it worth pointing out that the version tags can
> change anything,
> > > >including the length of the entire option?
> > > >
> > > >
> > > >
> > > >--Martin
> > > >
> > > >
> > > >
> > > >From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> > > >Sent: Thursday, 11 June 2009 2:25 PM
> > > >To: jmpolk@cisco.com; rbarnes@bbn.com; mlinsner@cisco.com
> > > >Cc: Thomson, Martin; geopriv@ietf.org
> > > >Subject: Datum field changes in RFC 3825bis (affecting
> Sections 2,
> > > >2.1 and 6.2)
> > > >
> > > >
> > > >
> > > >Can someone enter a ticket for this?
> > > >
> > > >Below are the proposed changes. Please review. The -01
> > > strawman with
> > > >these changes is available here:
> > > >http://www.drizzle.com/~aboba/GEOPRIV/draft-ietf-geopriv-rfc3
> > > 825bis-01.
> > > >txt
> > > >
> > > >In Section 2, change:
> > > >
> > > > 0 1 2
> 3
> > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> 6 7 8 9 0 1
> > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > +
> > > > | Code 123 | 16 | LaRes | Latitude
> > +
> > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > +
> > > > | Latitude (cont'd) | LoRes |
> > +
> > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > +
> > > > | Longitude
> > |
> > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > +
> > > > | AT | AltRes | Altitude
> > |
> > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > +
> > > > | Alt (cont'd) | Datum |
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >
> > > >To:
> > > >
> > > > 0 1 2
> 3
> > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> 6 7 8 9 0 1
> > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > +
> > > > | Code 123 | 16 | LaRes | Latitude
> > +
> > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > +
> > > > | Latitude (cont'd) | LoRes |
> > +
> > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > +
> > > > | Longitude
> > |
> > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > +
> > > > | AT | AltRes | Altitude
> > |
> > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > +
> > > > | Alt (cont'd) |Datum| Res |Ver|
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >
> > > >
> > > >In Section 2.1, change:
> > > >
> > > > The Datum byte has 256 possibilities, of which 3 have been
> > > > registered
> > > >
> > > >To:
> > > >
> > > > The Datum field is 3 bits, providing 8 possibilities, of
> > > which 3 have
> > > > been registered
> > > >
> > > >At the end of Section 2.1 add:
> > > >
> > > > The Res field which is 3 bits, is reserved. These bits have
> > been
> > > > used by [IEEE-802.11y], but are not defined within this
> > > > specification.
> > > >
> > > > The Ver field is two bits, and represents a version
> > > field, providing
> > > > for 4 potential versions.
> > > >
> > > >In Section 6.2, add:
> > > >
> > > >[IEEE-802.11y]
> > > > Information technology - Telecommunications and
> > > information
> > > > exchange between systems - Local and metropolitan area
> > > > networks - Specific requirements - Part 11:
> Wireless LAN
> > > > Medium Access Control (MAC) and Physical Layer (PHY)
> > > > specifications Amendment 3: 3650-3700 MHz
> > > Operation in USA,
> > > > November 2008.
> > > >
> > > >
> > > > > Date: Wed, 10 Jun 2009 15:56:49 -0500
> > > > > To: Bernard_Aboba@hotmail.com; rbarnes@bbn.com;
> > mlinsner@cisco.com
> > > > > From: jmpolk@cisco.com
> > > > > Subject: RE: Text for 3825bis
> > > > > CC: Martin.Thomson@andrew.com
> > > > >
> > > > > Bernard
> > > > >
> > > > > I assume you can make the edits about splitting the datum
> > > field into
> > > > > 3 parts, as I don't see that as controversial, and I
> > > think you have
> > > > > much of the idea from Richard, and can look in section 2 of
> > > > >
> > >
> http://www.ietf.org/internet-drafts/draft-polk-geopriv-3825-update-0
> > > > > 0.txt for how the datum field is being broken up.
> > > > >
> > > > > James
> > > >
> > > >
> > > >
> > > >-------------------------------------------------------------
> > > ----------
> > > >------------------------- This message is for the designated
> > > recipient
> > > >only and may contain privileged, proprietary, or
> otherwise private
> > > >information.
> > > >If you have received it in error, please notify the sender
> > > immediately
> > > >and delete the original. Any unauthorized use of this email is
> > > >prohibited.
> > > >-------------------------------------------------------------
> > > ----------
> > > >-------------------------
> > > >[mf2]
> > >
> > > _______________________________________________
> > > Geopriv mailing list
> > > Geopriv@ietf.org
> > > https://www.ietf.org/mailman/listinfo/geopriv
> > >
> --------------------------------------------------------------
> ----------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original. Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------
> ----------------------------------
> [mf2]
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
