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

[Hadriel Kaplan <[e-mail]>]

The email you cited from me below was when I announced the intention to submit.  I did actually submit it as 'Historic' in that 00 version - see here:
http://tools.ietf.org/html/draft-kaplan-insipid-session-id-00

I was then told to change it to Informational, which triggered this:
http://tools.ietf.org/html/draft-kaplan-insipid-session-id-01

I was told to put in context for why it's being published, which triggered this:
http://tools.ietf.org/html/draft-kaplan-insipid-session-id-02

I was told to fix some I-D nits, which triggered this:
http://tools.ietf.org/html/draft-kaplan-insipid-session-id-03

[I don't mean to imply I was told those separate things at separate times - it just took me several times to grok what I was being told :) ]

As you probably know, but others might not so I'm saying it here, you can view the diff changes between draft versions by clicking on the "diff1" or "diff2" links at the top of the HTML-based draft pages.

-hadriel


On Aug 6, 2013, at 3:13 PM, James Polk <[e-mail]> wrote:

> 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
>