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

[James Polk <[e-mail]>]

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