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

Hadriel

Will you at some point in the not too far future kindly do the necessary edits to gracefully park this draft in the archives as an RFC ??

Cheers

/atle

________________________________ 

Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation 
Ericsson

-----Original Message-----
From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Hadriel Kaplan
Sent: 13. mars 2013 23:44
To: Robert Sparks
Cc: <insipid@ietf.org>
Subject: Re: [Insipid] publishing draft-kaplan session-id as historic

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 <rjsparks@nostrum.com> 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 <HKaplan@acmepacket.com> 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
>>>> insipid@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/insipid
>>> _______________________________________________
>>> insipid mailing list
>>> insipid@ietf.org
>>> https://www.ietf.org/mailman/listinfo/insipid
>> _______________________________________________
>> insipid mailing list
>> insipid@ietf.org
>> https://www.ietf.org/mailman/listinfo/insipid
> 
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid

_______________________________________________
insipid mailing list
insipid@ietf.org
https://www.ietf.org/mailman/listinfo/insipid