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

[Mary Barnes <[e-mail]>]

On Tue, Aug 6, 2013 at 4:55 PM, DRAGE, Keith (Keith) <
[e-mail]> wrote:

> 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.
>
[MB] Probably it would be very helpful to ensure that point is captured in
the official minutes as well. [/MB]

>
> 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
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid
>