Re: [Insipid] publishing draft-kaplan session-id as historic

["DRAGE, Keith (Keith)" <[e-mail]>]

I understand this is intentional.

It apparently represents a change of philiosphy on the part of IESG, as relayed to us by Gonzalo, on how to represent this type of document.

Essentially it appears that they would rather use informational with the historical like status represented in the abstract or introduction, rather than use historical.

So Hadriel has merely been following instructions.

If you go listen to the INSIPID audio recording, you'll find we asked Gonzalo to explain this during the agenda bash and status discussion.

Regards

Keith



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of James Polk
> Sent: 06 August 2013 20:14
> To: Hadriel Kaplan; [e-mail]
> Subject: Re: [Insipid] publishing draft-kaplan session-id as historic
> 
> Hadriel
> 
> https://datatracker.ietf.org/doc/draft-kaplan-insipid-session-id/
> shows an intended status of "informational", not "historic" as you
> agreed. I believe that needs to be corrected.
> 
> James
> 
> At 03:36 PM 3/13/2013, Hadriel Kaplan wrote:
> > From today's meeting action I took... below was the email.
> >The difference between draft-kaplan-dispatch-session-id-03 and 02
> >can be seen here:
> >
> >http://tools.ietf.org/rfcdiff?url2=draft-kaplan-dispatch-session-id-
> 03.txt
> >
> >It did not change the ABNF nor protocol rules.  Therefore I propose
> >to submit 03 as independent submission to the RFC Editor, for
> >'Historic' status.  Or 'Epic' status if they have that. :)
> >
> >-hadriel
> >
> >
> >On Aug 17, 2012, at 1:47 PM, Hadriel Kaplan <[e-mail]>
> wrote:
> >
> > >
> > > When we talked about this in Vancouver I was thinking there
> > wouldn't be any problem going to/from UUID syntax, because going
> > to/from UUIDs in H.323 was talked about a long, long time ago for
> > session-id.  But I forgot about the bug in the draft-kaplan ABNF...
> > >
> > > Since version 01 of draft-kaplan-sip-session-id in 2008, which
> > later became draft-kaplan-dispatch-session-id, the rules for
> > generating the session-id always made it lower-case *hex*
> > characters.  I.e., the g-z range wasn't actually possible.  The
> > ABNF for it didn't get fixed until
> > draft-kaplan-dispatch-session-id-01 in April 2010, but that also
> > dropped it to 16 characters of hex because the algorithm changed,
> > and then 3 months later reverted back to 32 characters and the correct
> ABNF.
> > >
> > > So that begs the question of *which* version of draft-kaplan we
> > want to be backwards compatible with.  Since
> > draft-kaplan-dispatch-session-id-01 only existed for 3 months, I
> > think we can ignore that one.  And since everything else only used
> > hex characters, except the initial 00-draft which itself only
> > existed for 4 months, I think we can ignore that one too.
> > >
> > > Therefore, as far as I can tell we shouldn't have a problem
> > converting draft-kaplan session-ids to/from UUIDs for H.323/whatever.
> > >
> > > -hadriel
> > >
> > >
> > > On Aug 14, 2012, at 4:27 PM, Christer Holmberg wrote:
> > >
> > >> Hi,
> > >>
> > >> In Vancouver, I expressed a wish to make the INSIPID mechanism
> > backward compatible with the draft-kaplan-session-id one, the
> > reason being that it has been around for a relatively long time,
> > and has been implemented and deployed.
> > >>
> > >> I compared the suggested draft-jones solution with the
> > draft-kaplan solution, and I think there are ways to achieve
> > backward compability.
> > >>
> > >>
> > >> --------------
> > >>
> > >>
> > >> FIRST, looking purely at the ABNF syntax:
> > >>
> > >> The jones ABNF is:
> > >>
> > >>
> > >> Session-ID-UUID = "Session-ID-UUID" HCOLON UUID
> > >>
> > >>
> > >>
> > >> The kaplan ABNF is:
> > >>
> > >>
> > >>
> > >> Session-ID           =  "Session-ID" HCOLON sess-id
> > >>
> > >>                          *( SEMI generic-param )
> > >>
> > >> sess-id              =  32(DIGIT / %x61-7A)  ; 32 chars of [0-9a-z]
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Now, assuming 32 chars is enough to carry ONE UUID, jones
> > applications could put the SECOND UUID in a header field parameter
> > (generic-param), rather than combining it with the received UUID.
> > >>
> > >>
> > >>
> > >> Of course, the first UUDI (carried in sess-id) can only contains
> > characters 0-9 and a-z.
> > >>
> > >>
> > >>
> > >> A UUID can contain characters 0-9 and a-f and A-F.
> > >>
> > >>
> > >>
> > >> So, a jones entity would have to be prepared to receive g-z.
> > >>
> > >>
> > >>
> > >> And, as kaplan entity is not prepared to receive capital A-F, a
> > jones entity would have to only use small letters. But, that should
> > not be a problem, afaik, as they have the same meaning as far as
> > UUID is concerned.
> > >>
> > >>
> > >>
> > >> --------------
> > >>
> > >>
> > >>
> > >> SECOND, looking at it would work functionwise:
> > >>
> > >>
> > >>
> > >> There are two main alternatives:
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> 1. Second UUID is added even when one entity is kaplan compliant
> > >>
> > >> 2. Second UUID is not added when one entity is kaplan compliant
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Alternative 1:
> > >>
> > >>
> > >>
> > >> When a kaplan entity inserts the first UUID (I use that as a
> > general term, eventhough a kaplan entity does not use UUIDs), one
> > must assume that it is prepared to receive a response from a jones
> > entity which has added the second UUID into the header field parameter.
> > >>
> > >>
> > >>
> > >> When a jones entity inserts the first UUID, one must assume that
> > it is prepared to receive a response from a kaplan entity where the
> > second UUID has *not* been added.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Alternative 2:
> > >>
> > >>
> > >>
> > >> When a kaplan entity inserts the first UUID, the jones entity
> > detects (using some identify-a-kaplan-entity mechanism) that it
> > comes from a kaplan entity, so it does not insert a seoncd UUID in
> > the first place.
> > >>
> > >>
> > >>
> > >> As in alternative 1, when a jones entity inserts the first UUID,
> > it has to be prepared to receive a response where the second UUID
> > has not been added (the identify-a-kaplan-entity mechanism might
> > also inform the jones entity that the response comes from a kaplan
> entity.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> --------------
> > >>
> > >>
> > >>
> > >> Now, there will of course be cases, where two UUIDs are
> > required, that won't work. But, kaplan entities would be able to
> > use the session-id for whatever they've used it so far.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Regards,
> > >>
> > >>
> > >>
> > >> Christer
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> insipid mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/insipid
> > >
> > > _______________________________________________
> > > insipid mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/insipid
> >
> >_______________________________________________
> >insipid mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/insipid
> 
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid