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

[Hadriel Kaplan <[e-mail]>]

Yes sorry I should have been clearer - I realize I'll have to edit the doc to actually submit, I just meant using 03 as the version vs. 02 or 01 or whatever.

-hadriel


On Mar 13, 2013, at 5:04 PM, Robert Sparks <[e-mail]> wrote:

> On 3/13/13 4:36 PM, 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. :)
> It wouldn't be -03 as is - there needs to be an editing pass explaining this document's this is a proprietary something that may be in the wild. The text should be touched to make it an exposition (This is what you would have seen) vs a specification (this is what you should do).
> 
> RjS
> 
>> 
>> -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