Re: [Geopriv] Datum field changes in RFC 3825bis (affecting Sections 2, 2.1 and 6.2)

Since you clarify it, maybe it makes a difference.  Of course, the whole reason that we're doing this is because the old specification couldn't be used to create a sensible message in many cases.  Certainly we shouldn't be encouraging people to try to send the old encoding: that would be daft.

I'll create an issue: Should not encourage use of "old" encoding

> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> Sent: Tuesday, 23 June 2009 10:04 AM
> To: Thomson, Martin; 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)
> 
> Read the text.
> 
> 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]
> >
------------------------------------------------------------------------------------------------
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]